Date: Mon, 21 Apr 2014 17:11:50 +1000 From: Robert Backhaus <robbak@robbak.com> To: ports@freebsd.org Subject: Problems with include and lib order Message-ID: <CABG_4jmtujz-sNUSC6%2Bj4gR1pvBqnEFfKZr52Lspvd-a2RbY0w@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
This is a problem which I think is happening at many places within the
ports tree, but often isn't being recognised.
Say a port uses liba and libz. Liba is a common, say graphics library port.
It is a required port, and installs in /usr/local/include/liba.h and
usr/local/lib/liba.so . Libz is also fairly common, and many of us have the
port installed, again in /usr/local/{include|lib}, but this version is
slightly incompatible with this port - It may build and run, but might
trigger some hidden corner case. Because os this, the port builds it's own
libz in $BUILDDIR/libs/libz.
When the ports system/.configure/qmake/etc. system goes through all of
this, it often ends up using g++ -I/usr/local/include -Ilibs/libz
-osource.o source.cpp; and then linking with -L/usr/local/lib -Llibs/libz .
This will DTWT.
At the moment, this is dealt with on a piecemeal basis whenever it is
recognized, wherever it causes build failures or gratuitous runtime
problems. But this leaves cases where the failure only shows up as random
crashes for a few people, or where the fault is in rare communications
between peer clients
I would like to see some ways to deal with this in a more generic way -
changes within the qmake/autotools/ports system to always adjust include
and lib path orders to move /usr/local/include to the very end.
Or a 'real fix' - adjust all library ports to always install the
include/lib files in /usr/local/{include|lib}/libname/... But that one
would be too hard!
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CABG_4jmtujz-sNUSC6%2Bj4gR1pvBqnEFfKZr52Lspvd-a2RbY0w>