Re: Need to use some library path before /usr/lib
Gerald Pfeifer wrote: On Thu, 17 Sep 2009, Jason J. Hellenthal wrote: 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 That looks quite nice, and I was going to use that, alas I cannot seem to make it work. Is it possible that libmap.conf does not work when the name on the left-hand side is the same as on the right-hand side? It must be an exact (i.e., per-binary file) constraint, unless we enforce the requirement that all ports that have binaries in the directory are compiled with the same compiler. There is no way that I can see to do this in the current Ports framework without separate PREFIXes and LOCALBASEes, which would result in undesired redundancies. And I don't think that all ports respect non-default PREFIXes and LOCALBASEes, although there is ongoing work in this direction. However, if exact constraints are used throughout this file, I wonder if performance will suffer as the size of libmap.conf grows much larger. I suspect the answer to this problem does not involve libmap.conf, at least in it's current form. One of the advantages of the current Ports framework is that, within limits, different compilers may be used for different ports. I don't think that users want to give up the ability to define CC. Even if they did, we're still stuck with shared objects from the base system that depend upon the libraries of the base system compiler. (As an aside, NetBSD just brought the latest binutils into their base system, and DragonFly has imported gcc 4.4. Why is it that these projects, that have similar licensing goals, have made a pragmatic choice to use select GPLv3 code, at least until BSD-licensed equivalents are available, and we haven't?) 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. That might work, though it looks like a lot of work. It occurs to me we really need to set this globally. See above. That is one of the implications those that always pushed for having ports use a distinct compiler may have missed. That, or using -rpath. Loren, how would we best have GCC automatically add -rpath=/usr/local/lib/gcc44 to every invocation? Presumably spec magic? Probably, because not every port uses or respects LDFLAGS and CFLAGS. (Some of them don't even respect CC.) But what about those ports that invoke the linker directly, not through the compiler? There will have to be a big LDFLAGS cleanup. Also, will changing -rpath be sufficient? I doubt it: we may have to clean up linking statements in ports, and probably rename some libraries, so that no objects are linked that in turn require different and incompatible shared libraries with the same name. (In that sense, this thread is probably misnamed.) b. ___ 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
Re: Need to use some library path before /usr/lib
In article alpine.lsu.1.99.0909202328340.5...@acrux.dbai.tuwien.ac.at, Gerald Pfeiferger...@pfeifer.com writes: On Thu, 17 Sep 2009, Jason J. Hellenthal wrote: 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 That looks quite nice, and I was going to use that, alas I cannot seem to make it work. Is it possible that libmap.conf does not work when the name on the left-hand side is the same as on the right-hand side? Why don't you just install /usr/local/lib/gcc44/libstdc++.so with a different version number? There is no requirement to sequentially assign numbers thus: use 10MmX where X is the number assigned by GNU and Mm is the major/minor number as used by the port. Then, install in standard port place and let standard rules find the right library. (e.g. lang/gcc44 would use: /usr/local/lib/libstdc++.so.10446; lang/gcc45 would use: /usr/local/lib/libstdc++.so.10456) 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). It wouldn't really help since the resulting binaries need the very same workaround. 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. That might work, though it looks like a lot of work. It occurs to me we really need to set this globally. That is one of the implications those that always pushed for having ports use a distinct compiler may have missed. That, or using -rpath. Loren, how would we best have GCC automatically add -rpath=/usr/local/lib/gcc44 to every invocation? Presumably spec magic? I can't vouch for having tested it recently (or ever) but: Add --enable-rpath to the configure line. Regards, Loren ___ 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
Re: Need to use some library path before /usr/lib
On Thu, 17 Sep 2009, Jason J. Hellenthal wrote: 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 That looks quite nice, and I was going to use that, alas I cannot seem to make it work. Is it possible that libmap.conf does not work when the name on the left-hand side is the same as on the right-hand side? 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). It wouldn't really help since the resulting binaries need the very same workaround. 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. That might work, though it looks like a lot of work. It occurs to me we really need to set this globally. That is one of the implications those that always pushed for having ports use a distinct compiler may have missed. That, or using -rpath. Loren, how would we best have GCC automatically add -rpath=/usr/local/lib/gcc44 to every invocation? Presumably spec magic? Gerald -- Gerald (Jerry) Pfeifer ger...@pfeifer.com http://www.pfeifer.com/gerald/ ___ 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
Re: Need to use some library path before /usr/lib
Thanks for considertion... Anything else? Simply back out for this moment, until we have some clues.. From: Gerald Pfeifer ger...@pfeifer.com Subject: Need to use some library path before /usr/lib Date: Thu, 17 Sep 2009 18:45:10 +0200 (CEST) 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? +1 but I fear there can be a regression Any pointers on how to best implement an ordering of search paths for ldconfig (or rpath, if that is the best of options)? -- Nakata Maho http://accc.riken.jp/maho/ , http://ja.openoffice.org/ Nakata Maho's PGP public keys: http://accc.riken.jp/maho/maho.pgp.txt pgpN5Mo3SKAV9.pgp Description: PGP signature
Need to use some library path before /usr/lib
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 ___ 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
Re: Need to use some library path before /usr/lib
On Thu, 17 Sep 2009 12:45 -, 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. -- 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
