Date: Thu, 17 Sep 2009 21:43:58 -0400 From: "Jason J. Hellenthal" <jasonh@DataIX.net> To: "Jason J. Hellenthal" <jasonh@DataIX.net> Cc: ports@freebsd.org, Loren James Rittle <rittle@labs.mot.com>, Gerald Pfeifer <gerald@pfeifer.com> Subject: Re: Need to use some library path before /usr/lib Message-ID: <alpine.BSF.2.00.0909172139010.1520@qvzrafvba.5c.ybpny> In-Reply-To: <alpine.BSF.2.00.0909172117140.1520@qvzrafvba.5c.ybpny> References: <alpine.LSU.1.99.0909171832060.15831@acrux.dbai.tuwien.ac.at> <alpine.BSF.2.00.0909172117140.1520@qvzrafvba.5c.ybpny>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 17 Sep 2009 21:24 -0000, jasonh wrote: > On Thu, 17 Sep 2009 12:45 -0000, gerald wrote: > >> Building some (Fortran) applications with lang/gcc44 it turns out we get >> weird failures upon startup which look like: >> >> /libexec/ld-elf.so.1: /usr/lib/libstdc++.so.6: version GLIBCXX_3.4.11 >> required by ./gendoc not found >> >> What is happening here is that lang/gcc44 lays down >> /usr/local/lib/gcc44/libstdc++.so.6 >> and puts /usr/local/lib/gcc44 into USE_LDCONFIG. Alas the system then >> finds and uses /usr/lib/libstdc++.so.6 from our aging system compiler >> instead. >> >> Now, both libraries share the same name/version because these libraries, >> like also (and especially) libgcc_s.so.1 because new versions are drop >> ins for older ones, but not the other way round. >> >> How can we address this? >> >> Updating the old, unsupported by upstream system compiler has >> been ruled out historically, and does not look like an option (and also >> would not help older versions of FreeBSD). >> >> Use -rpath, somehow, by changing the configuration of the >> lang/gcc44 ports? That sucks in that it will break updates to newer >> versions of GCC. >> >> Set up ldconfig such that /usr/local/lib/gcc44 comes before >> /usr/lib? >> >> Anything else? Any pointers on how to best implement an ordering of >> search paths for ldconfig (or rpath, if that is the best of options)? >> >> Gerald >> >> > > Would it be possible to just libmap.conf gcc44 and friends just for that lib > and the programs it builds. I know this is not such a great solution but for > the mean time it may be a relevant answer. > Something like the following. [/usr/local/bin/] libstdc++.so /usr/local/lib/gcc44/libstdc++.so libstdc++.so.6 /usr/local/lib/gcc44/libstdc++.so.6 On a second note. It would be real nice if the install of a second/third compiler would get installed into its own directory rather than placing executables in /usr/local/bin/ place them /usr/local/lib/gcc44/bin and create the symlinks to them. This would at least help the libmap issue and gcc44 for several ports (just building). Now for a port running (octave as example) have that port spam libmap.conf with the proper configuration for just that port the same way perl does to make.conf. -- Jason J. Hellenthal http://www.DataIX.net/ jasonh@DataIX.net 0x691411AC - (2^(N-1))
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.0909172139010.1520>