[Bond-users] Scons build build problems

[Colin Close]

I have been trying to compile Bond to use some system debug libraries 
and I have discovered some very strange behavior which has caused me two 
days of head scratching.
Basically the problem seems to be that the Bond build system has a 
greater affinity for /usr/local/lib that it has for the system library 
directory /usr/lib64 (At least this is so on Mandriva 64 bit edition). 
Despite setting the PKG_CONFIG_PATH correctly if there is one library 
that is required to build Bond existing in  /usr/local/lib then scons 
will grab this and then fail because the dependent libs are not in 
/usr/local/lib.
This will happen even if one of the libraries is a broken symbolic 
link!!! i.e. a link to a library that is no longer installed!!
This behavior seems to be caused by the way scons constructs the link 
commands here is an example:-

cc -o src/barcode.os -c -DUNIX -g -O -Wall -DGNU_SOURCE -DMEM_TEST 
-DNO_EMAIL_SUPPORT -pthread -fPIC -DORBIT2=1 -I/usr/local/include/bond 
-I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include 
-I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 
-I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include 
-I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/libxml2 
-I/usr/include/libgnomeui-2.0 -I/usr/include/libgnome-2.0 
-I/usr/include/libgnomecanvas-2.0 -I/usr/include/libart-2.0 
-I/usr/include/gconf/2 -I/usr/include/libbonoboui-2.0 
-I/usr/include/gnome-vfs-2.0 -I/usr/lib64/gnome-vfs-2.0/include 
-I/usr/include/gnome-keyring-1 -I/usr/include/orbit-2.0 
-I/usr/include/libbonobo-2.0 -I/usr/include/bonobo-activation-2.0 
src/barcode.c
scons: *** Source `/usr/local/lib/libcairo.a' not found, needed by 
target `src/libbond.so'.  Stop.
scons: building terminated because of errors.
[root at passmache trunk]#

In this case libcairo.a a broken symbolic link, which is not even a 
required library and would not link anyway; is called by scons and 
linking fails. This will happen if you have ANY of libraries mentioned 
in the link line in /usr/local/lib.
It is possible to have a combination of system libraries and local 
libraries linked in dependent on what scons finds in /usr/local/lib what 
is more these libraries can be incompatible with each other which 
results in missing features and non-funtionality in bond which I have 
previously interpreted incorrectly as bugs!! ( My last mail!!!)

Why does this happen the following link lines provide the answer:--
gcc -o src/bondfrontend -Wl,--export-dynamic -pthread src/bondrelation.o 
src/bondapi.o src/bondfilter.o src/biglists.o src/bondmain.o 
src/dropdown.o src/bondargument.o src/postit.o src/bond.o 
src/watchtower.o src/search.o src/bondtrigger.o src/bondxml.o 
src/xml_funcs.o src/xml_display.o src/evaluate.o src/uiplugin.o src/ui.o 
src/uicommonplugin.o src/uidropdown.o src/condition.o src/bondmanage.o 
src/bondtest.o src/livesql.o src/security.o src/fileio.o src/filesql.o 
src/bondlink.o src/bondpaint.o src/bondsave.o src/matrix.o src/sqlerr.o 
src/bondxmlcommon.o src/xmlinit.o src/intlisttree.o src/bondtutorial.o 
src/autosize.o src/email.o src/schemaupdate.o src/barcode.o 
src/bondfrontend.o

-L/usr/local/lib -lbonddb2 -lbondcommon -lbondsql -lxml2 -lgnomeui-2 
-lSM -lICE -lbonoboui-2 -lgnomevfs-2 -lgnome-keyring -lgnomecanvas-2 
-lgnome-2 -lpopt -lart_lgpl_2 -lpangoft2-1.0 -lgtk-x11-2.0 -lgdk-x11-2.0 
-latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lpango-1.0 -lcairo 
-lbonobo-2 -lbonobo-activation -lgconf-2 -lgmodule-2.0 -ldl -lORBit-2 
-lgthread-2.0 -lrt -lgobject-2.0 -lglib-2.0

Notice the -L line (separated out) it instructs the linker to link from 
/usr/local/lib before anything else only after that are the system 
libraries read, at least that is what happens on my system. I tried 
adjusting LD_LIBRARY_PATH to try to overcome this behavior to no avail; 
Next I tried modifying the SConstruct file to attempt to isolate the 
bond libs like the following:-

-lxml -lgnomeui .....etc -L/usr/local/lib -lbonddb2 -lbondcommon....etc

Scons however had other ideas and reverted to placing the library path 
line before the libraries which is not what I wanted.  Trying to 
introduce the system library path by setting environment variables for 
pkg-config to cause it to generate the -L line for every library failed 
because scons simply stripped them out. I tried re-ordering the 
detection that failed too scons simply put the files in the order it 
thought fit.
As far as I could discover there just didn't seem any way around the 
problem I am sure there must be but I couldn't find it.
Ultimately all I could do was to uninstall every bond related lib from 
/usr/local/ (even broken symlinks!!)
and compile like that.

You may ask how I got into this mess!! Well I run KDE so most of the 
libs required by Bond aren't installed by default however the Gnome lib 
dependencies are many and varied so you start installing them from 
repositories however scons has yet another gotcha up its sleeve or maybe 
its pkg-config anyways what happens is that  when the check are run for  
by scons for the required libraries  pkg-config  returns ) if it find 
the library requested it does not seem to check for the dependencies 
thus scons says everything is OK but fails to build because of missing 
libraries (private requires in *.pc files seem to be the offender). So 
what do you do well I downloaded the source and compiled the missing lib 
of course from there on in because of the /usr/local/lib thing you are 
on a slippery slope to hell!!

I apologise for the long and rambling email but I like bond and it realy 
is coming along nicely and it would be a shame if people did not use it 
because they couldn't build it. Perhaps reversion to the old
autoconf configure & make system for the time being could be considered.


Best

Colin Close