------- 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