Date: Mon, 21 Sep 2009 06:59:37 +0000 From: "b. f." <bf1783@googlemail.com> To: freebsd-ports@FreeBSD.org Cc: gerald@pfeifer.com Subject: Re: Need to use some library path before /usr/lib Message-ID: <d873d5be0909202359m2467111egc463f09bb075f492@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?d873d5be0909202359m2467111egc463f09bb075f492>