Need to use some library path before /usr/lib

b. f. bf1783 at
Mon Sep 21 06:59:38 UTC 2009

Gerald Pfeifer wrote:
>On Thu, 17 Sep 2009, Jason J. Hellenthal wrote:
>> Something like the following.
>> [/usr/local/bin/]
>>            /usr/local/lib/gcc44/
>>          /usr/local/lib/gcc44/
>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

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


More information about the freebsd-ports mailing list