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

["david dot kirkby at onetel dot net" <gcc-bugzilla@gcc.gnu.org>]

------- Comment #16 from david dot kirkby at onetel dot net  2010-01-15 09:59 -------
Subject: Re:  gcc fails to build on Solaris x86 - it
 forgets the locations of libmpfr

BlanchardJ at ieee dot org wrote:
> ------- 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
> 
> 
Yes, thank you. That is helpful. How do you produce the $ISALIST? Is that
simply 
sparcv9 on a modern SPARC and amd64 on an Open Solaris system, or is it a list. 
If the latter, how do you every it.


drkirkby@hawk:~$ isalist
amd64 pentium_pro+mmx pentium_pro pentium+mmx pentium i486 i386 i86

Do I need

xport LD_OPTIONS='-R/opt/csw/lib/amd64 -R opt/csw/lib/pentium_pro+mmx etc" ? I 
doubt it, but I'm not sure what you mean there.

Is it just this, or anything else I need to do? You say "typical blastwave
build 
would have at a minimum .." but I doubt you would consider gcc a "typical 
blastwave build" If there are further complications, can you let me know what 
they are.

Dave


-- 


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