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