[Bond-users] [Fwd: Re: [Fwd: Scons build build problems]]
Colin Close
itchka at compuserve.com
Thu Dec 13 21:39:54 EST 2007
Hi Guys,
I've attached a patch for SConstruct also the final output of a link line.
What I have done is not pretty but it works. As you can see from the
link line the bond libs and their path now appear at the end of the link
command which ensures that any system libraries get pulled in first. I
think this will also work if pkg-config returns library paths other than
the system ones.
There is one further problem that might occur at run time if a user
after compiling and installing bond does at a later date compile and
install a dependent library. This could inadvertently break bond.
I have run a test to try this and bond still appears to pull in the
correct libraries, I even re-compiled with the rogue library in place
and it still got it right so I guess an -rpath line may only be
necessary if one wishes to have a bunch of unstripped debug libraries in
/usr/local/lib.
Anyways see what you think of the solution!
BTW thanks for including me in the loop.
Best
Colin Close
Dru wrote:
>
>
>
>
> ------------------------------------------------------------------------
>
> Subject:
> Re: [Fwd: [Bond-users] Scons build build problems]
> From:
> jasen at tyreal.treshna.com
> Date:
> Thu, 13 Dec 2007 13:44:13 +1300
> To:
> Dru <dru at treshna.com>
>
> To:
> Dru <dru at treshna.com>
>
>
> On Wed, Dec 12, 2007 at 09:24:08PM +1300, Dru wrote:
>
>> i dont know. jasen will know better than me
>>
>
> This seems to be a problem with scons ordering the compiler flags as
> it sees fit. It seems that it doesn't effect people who have all
> (or most of) the GTK libraries installed in /usr/lib (until recently
> we had libgoocanvas in /usr/local/lib)
>
> Scons stores the library names and paths in separate lists so there is
> no easy way to fix scons.
>
> What is possbile is to empty the libraries and libdirs lists and put
> all that stuff in the linkflags list. Getting that right automatically
> could be hard, we'd have to replace Environment::ParseConfig with one
> that parses the link options into LDFLAGS instead of into LIBS and
> LIBDIRS and that's assuming that pkg-config is working correctly on
> his system.
>
> I think the first steps are to
> a) Find a link command that works,
>
> b) Findout if pkgconfig gives sufficiently detailed information
> to produce that link command.
>
> Given that scons is python based, with those prerequisites satisfied
> it must be possbile to find a path from b to a
>
> Allowing a command-line option to override LIBS and LIBDIRS might work for
> Colin if he doesn't mind entering half a page of flags.
>
> The problem with going back to automake is that last time I tried I
> couldn't get it to build windows binaries, I don't claim to understand
> how autotools work, it's been a couple of years so they may have
> changed things now so that it will work.
>
>
>> Liam O'Boyle wrote:
>>
>>> I'm not sure what the appropriate behaviour here is... should we use the
>>> PKG_CONFIG_PATH if it's set and otherwise use our default /usr/local?
>>>
>>> On Mon, 2007-12-10 at 15:45 +1300, Dru wrote:
>>>
>>>
>>>> Hello.
>>>>
>>>> Yes ideally we look at the envoriment variables. I have
>>>> an example of this i think in bonddb2
>>>>
>>>>
>>>> Liam O'Boyle wrote:
>>>>
>>>>
>>>>> Should I fix this? I guess we just check if the environment variable is
>>>>> set, and use that if so, otherwise go with our current behaviour.
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------
>>>>>
>>>>> Subject:
>>>>> [Bond-users] Scons build build problems
>>>>> From:
>>>>> Colin Close <itchka at compuserve.com>
>>>>> Date:
>>>>> Tue, 04 Dec 2007 19:16:55 -0500
>>>>> To:
>>>>> Bond Users <bond-users at hcoop.net>
>>>>>
>>>>> To:
>>>>> Bond Users <bond-users at hcoop.net>
>>>>>
>>>>>
>>>>> 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.
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------
>>>>>
>>>>> _______________________________________________
>>>>> Bond-users mailing list
>>>>> Bond-users at hcoop.net
>>>>> http://hcoop.net/cgi-bin/mailman/listinfo/bond-users
>>>>>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bond_sconstruct_patch.gz
Type: application/gzip
Size: 1361 bytes
Desc: not available
Url : http://hcoop.net/pipermail/bond-users/attachments/20071213/4eaa13e1/attachment.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: link_output.txt.gz
Type: application/gzip
Size: 496 bytes
Desc: not available
Url : http://hcoop.net/pipermail/bond-users/attachments/20071213/4eaa13e1/attachment-0001.bin
More information about the Bond-users
mailing list