[Fwd: Re: [Fwd: Scons build build problems]]

[Dru-2]

--
Andrew Hill
treshna Enterprises Ltd
Tel: [phone]
Cel: 021 660 819
Web: www.treshna.com
IT Consultancy - Websites - Database development - Computer tech support


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@...>
> >>> Date:
> >>> Tue, 04 Dec 2007 19:16:55 -0500
> >>> To:
> >>> Bond Users <bond-users@...>
> >>>
> >>> To:
> >>> Bond Users <bond-users@...>
> >>>
> >>>
> >>> 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.
> >>>

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

[Colin Close]

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@...
> Date:
> Thu, 13 Dec 2007 13:44:13 +1300
> To:
> Dru <dru@...>
>
> To:
> Dru <dru@...>
>
>
> 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@...>
>>>>> Date:
>>>>> Tue, 04 Dec 2007 19:16:55 -0500
>>>>> To:
>>>>> Bond Users <bond-users@...>
>>>>>
>>>>> To:
>>>>> Bond Users <bond-users@...>
>>>>>
>>>>>
>>>>> 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.
>>>>>
>>>>>          
>>>>> ------------------------------------------------------------------------
>>>>>
>>>>> _______________________________________________
>>>>> Bond-users mailing list
>>>>> Bond-users@...
>>>>> http://hcoop.net/cgi-bin/mailman/listinfo/bond-users
>>>>>          

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

[jasen]

On Thu, Dec 13, 2007 at 09:39:54PM -0500, Colin Close wrote:
> 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.

I'm glad it works for you, it _almost_ works here, at the link stage scons
produces a command on stdout that works if pasted on the command-line, but
runs something different which fails.

when the SCONS guys finally get their command-line argument quoting
code fixed correctly it'll stop working entirely.

Scons version 0.97-1ubuntu

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

[Colin Close]

Mmm Jasen
they must have fixed/changed something already as I'm using scons
0.96.93.  I know what I have done its a horrible hack but there seems to
be no other obvious way to position the -L flags anywhere else but at
the beginning of the libraries. I suppose one answer is to write ones
own execution environment. Are you suggesting that the pkg-config trick
(obviously without all the 'echo' stuff) won't work either once they
sort the quoting. The problem I had was that the command line I was
trying to use was always in double quotes which of course caused the
pkg-config command to fail.
Is there a sloution to this?

Best

Colin Close

jasen@... wrote:

>  
> On Thu, Dec 13, 2007 at 09:39:54PM -0500, Colin Close wrote:
>  
>> 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.
>>    
>
> I'm glad it works for you, it _almost_ works here, at the link stage scons
> produces a command on stdout that works if pasted on the command-line, but
> runs something different which fails.
>
> when the SCONS guys finally get their command-line argument quoting
> code fixed correctly it'll stop working entirely.
>
> Scons version 0.97-1ubuntu
>
> _______________________________________________
> Bond-users mailing list
> Bond-users@...
> http://hcoop.net/cgi-bin/mailman/listinfo/bond-users
>
>  

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

[jasen]

On Sun, Dec 16, 2007 at 05:26:14PM -0500, Colin Close wrote:

> Mmm Jasen
> they must have fixed/changed something already as I'm using scons
> 0.96.93.  I know what I have done its a horrible hack but there seems to
> be no other obvious way to position the -L flags anywhere else but at
> the beginning of the libraries. I suppose one answer is to write ones
> own execution environment. Are you suggesting that the pkg-config trick
> (obviously without all the 'echo' stuff) won't work either once they
> sort the quoting. The problem I had was that the command line I was
> trying to use was always in double quotes which of course caused the
> pkg-config command to fail.
> Is there a sloution to this?

when they sort the quoting gcc will see arguments containing the
backtick as strings with the backtick in them.

hopefully they'll get to the ordering issue first.

I'm guessing you could turn it on its head and put all the other flags
and libraries and flags in the LINKFLAGS

I think you can use
 
  env.Append(LINKFLAGS = Split(`pkg-config .....`));

I might try that later.

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

[Colin Close]

Thanks Jasen I'll give it a try here too.
Has anyone reported a bug on the ordering problem?

Incidently I can see why they thought it was alright because the gcc/ld
manpages are a bit ambiguous on this point.

Best

Colin

jasen@... wrote:

>  
> On Sun, Dec 16, 2007 at 05:26:14PM -0500, Colin Close wrote:
>  
>> Mmm Jasen
>> they must have fixed/changed something already as I'm using scons
>> 0.96.93.  I know what I have done its a horrible hack but there seems to
>> be no other obvious way to position the -L flags anywhere else but at
>> the beginning of the libraries. I suppose one answer is to write ones
>> own execution environment. Are you suggesting that the pkg-config trick
>> (obviously without all the 'echo' stuff) won't work either once they
>> sort the quoting. The problem I had was that the command line I was
>> trying to use was always in double quotes which of course caused the
>> pkg-config command to fail.
>> Is there a sloution to this?
>>    
>
> when they sort the quoting gcc will see arguments containing the
> backtick as strings with the backtick in them.
>
> hopefully they'll get to the ordering issue first.
>
> I'm guessing you could turn it on its head and put all the other flags
> and libraries and flags in the LINKFLAGS
>
> I think you can use
>  
>   env.Append(LINKFLAGS = Split(`pkg-config .....`));
>
> I might try that later.
>
> _______________________________________________
> Bond-users mailing list
> Bond-users@...
> http://hcoop.net/cgi-bin/mailman/listinfo/bond-users
>  

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