Problems with include and lib order

[Robert Backhaus]

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!