Need to use some library path before /usr/lib

Jason J. Hellenthal jasonh at DataIX.net
Fri Sep 18 01:44:00 UTC 2009


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 at DataIX.net
  0x691411AC

  - (2^(N-1))


More information about the freebsd-ports mailing list