[Bug bootstrap/36481] gcc fails to build on Solaris x86 - it forgets the locations of libmpfr

["BlanchardJ at ieee dot org" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #15 from BlanchardJ at ieee dot org  2010-01-15 05:12 -------
(In reply to comment #14)
> (In reply to comment #10)
> > In reply to #9:
> > 
> > I have tried to build gcc with and without my own patch on our solaris
> > machines. While both of them fails they fail at the same place (namely
> > configuration of [arch]/libgcc trying to figure out the object suffix). They 
> 
> It would be good if a patch similar to yours will work, so alloing gcc to be
> installed in an arbitrary location and used without setting LD_LIBRARY_PATH. 
> 
> The fact is, a lot of people using Solaris do not have root access, so using
> crle is not an option. 
> 
> It should be noted, gcc binaries from Blastwave install in a non standard
> location (/opt/csw) and do run without the user having to set LD_LIBRARY_PATH.
> Of course, you need root acces to install them, but they do *not* modify the
> linker search path with crle, but work without doing that. 
> 
> Despite asking a couple of times, I've never managed to get an answer how the
> Blastwave binaries achieve this. 
> 
> I'd like a pound (I'm English) for every time I have seen this issue raised on
> Solaris forums. It is something wanted by many, but I believe the gcc
> developers do not feel is necessary. 
> 
> Some have told be /usr/local is "a standard" though it's not a "standard"
> reconised by any official body, like ISO, IEEE etc. But normal users cant write
> there either.
> 
> PS, you could always ask your uni system admins if they would set you up in a
> Solaris 10 zone. The memory overhead of a zone is quite small (well under 100
> MB) and if in a zone, they could give you root access. 
> 
> Dave 
> 

We modify the runpaths of the final binaries to achieve this results. It is
done the same way with nearly all of our packages.

There is a few way of doing this but the most reliable one is as follow :

Define the LD_OPTIONS env variable before building gcc and use it to add the
correct runtime path.

for example a typical blastwave build would have at a minimum :

export LD_OPTIONS='-R/opt/csw/lib'

In this case the final shared libraries will contain runtime search paths to
find stuff in /opt/csw/lib. Now there is a catch though if you want to build a
multilib gcc for the gcc build you should use :

export LD_OPTIONS='-R/opt/csw/lib/$ISALIST'

In this case the libraries will be able to search for 64 or 32 bit libs
accordingly.

Hope this help,

Jonathan Blanchard


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36481