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@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



_______________________________________________
Bond-users mailing list
Bond-users@...
http://hcoop.net/cgi-bin/mailman/listinfo/bond-users