------- 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. drkir...@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
