path to find libcc1.so?

[Jan Kratochvil]

On Sat, 13 Dec 2014 01:22:38 +0100, Doug Evans wrote:
> I was reading the new "compile" code and a question occurred to me.
> Do we want to give the user a parameter to specify the path of libcc1.so?
> (say if it's in a non-standard location)
> Or is the plan to tell users to use existing mechanisms
> (LD_LIBRARY_PATH, et.al.)?

It is assumed + I use $LD_LIBRARY_PATH.

I find the GDB compile project is at much too early stage than to care about
this.  It needs some additional features (such as to use it by default for the
"print" command etc. etc.) to make it really practically useful, additionally
it will be useful IMO only since the C++ support which is a new project ahead.

But if we should care about it: I think libcc1.so can be arbitrary one, it
only provides RPC interface to the target compiler which it
fork()s+exec()utes.  Target compiler is already being search to match the
inferior arch (see GDB gdbarch's gnu_triplet_regexp).  There is gdb<->libcc1
version check (GCC_FE_VERSION_0) and libcc1<->gcc version check
(GCC_C_FE_VERSION_0) but so far there exists only one protocol version so
I also find a bit premature to deal with searching for matching libcc1 when
currently any one has to match.

I wanted to try to check how does it search+work with s390x cross target but
I failed to build gcc-5.0 for s390x, filed:
	s390x, ICE, unable to generate reloads, in curr_insn_transform, at lra-constraints.c
	https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64300


On Sat, 13 Dec 2014 08:53:02 +0100, Eli Zaretskii wrote:
> > Date: Fri, 12 Dec 2014 16:22:38 -0800
> > From: Doug Evans <dje@google.com>
> > Cc: gdb-patches <gdb-patches@sourceware.org>
> > 
> > I was reading the new "compile" code and a question occurred to me.
> > Do we want to give the user a parameter to specify the path of libcc1.so?
> 
> Shouldn't "gcc -print-file-name" know how to find it?

While 'gcc -print-file-name=libcc1.so' really works for me it brings
a chicken-and-egg problem.

Currently the search for a matching compiler (like x86_64-redhat-linux-gcc
vs. s390x-linux-gnu-gcc) is being done by libcc1.so which ... is backwards.


Jan