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/
jas...@dataix.net
0x691411AC
- (2^(N-1))
_______________________________________________
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
