From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22088 invoked by alias); 15 Jan 2010 13:15:57 -0000 Received: (qmail 22039 invoked by alias); 15 Jan 2010 13:15:41 -0000 Date: Fri, 15 Jan 2010 13:15:00 -0000 Message-ID: <20100115131541.22038.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug bootstrap/36481] gcc fails to build on Solaris x86 - it forgets the locations of libmpfr In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "david dot kirkby at onetel dot net" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2010-01/txt/msg01868.txt.bz2 ------- Comment #18 from david dot kirkby at onetel dot net 2010-01-15 13:15 ------- Subject: Re: gcc fails to build on Solaris x86 - it forgets the locations of libmpfr BlanchardJ at ieee dot org wrote: > ------- Comment #17 from BlanchardJ at ieee dot org 2010-01-15 12:37 ------- > >> 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 >> > > Hi, > > It's just the string '$ISALIST' so it will appear as-is in the final run path. > The runtime linker will take care of expanding it correctly at runtime. So one > just export LD_OPTIONS as-is before building. > > Thank you. That's very helpful. I really hate having to set LD_LIBRARY_PATH - it is particularly an issue if you have multiple compilers. There's alyways the chance it gets set to the wrong compiler by mistake. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36481