[Scons-users] Problems with ParseFlags()

[William Blevins]

Oh! Do --cflags instead. SCons expects compiler flags and not linker flags
:)

I just reviewed the pkg-config man page. Try "--cflags". I should look at
the SCons User Guide and see what it says now.

V/R,
William

On Sun, Mar 27, 2016 at 1:33 PM, William Blevins <wblevins001 at gmail.com>
wrote:

> Which version of gcc are you using? I assum gcc/g++ because of FreeBSD.
>
> On Sun, Mar 27, 2016 at 3:40 AM, Fred Wright <fw at fwright.net> wrote:
>
>>
>> On Sun, 27 Mar 2016, William Blevins wrote:
>>
>> > Please always specify your version of SCons and python. Other inline
>> > comments below.
>>
>> $ scons --version
>> SCons by Steven Knight et al.:
>>         script: v2.4.1.rel_2.4.1:3453:73fefd3ea0b0, 2015/11/09 03:25:05,
>> by bdbaddog on ubuntu1404-32bit
>>         engine: v2.4.1.rel_2.4.1:3453:73fefd3ea0b0, 2015/11/09 03:25:05,
>> by bdbaddog on ubuntu1404-32bit
>>         engine path: ['/usr/local/lib/scons-2.4.1/SCons']
>> Copyright (c) 2001 - 2015 The SCons Foundation
>> $ head `which scons`
>> #!/usr/local/bin/python2.7
>>
>> > On Sat, Mar 26, 2016 at 10:23 PM, Fred Wright <fw at fwright.net> wrote:
>> >
>> > >
>> > > I recently had to track down the reason that attempts to build GPSD on
>> > > FreeBSD with ncurses enabled were crashing scons.  The trigger was the
>> > > pkg_config data that FreeBSD has for ncurses:
>> > >
>> > > $ pkg-config --libs ncurses
>> > > -L/usr/local/lib -rpath /usr/local/lib  -lncurses -ltinfo
>> > >
>> > > I believe the -rpath is completely redundant in this context, but
>> > > nevertheless that's how the FreeBSD pkg-config has it set up for
>> ncurses
>> > > (and 11 other packages among the ones I have installed).  Feeding
>> this to
>> > > ParseFlags() leads to a chain of problems:
>> > >
>> > > 1) ParseFlags() doesn't recognize -rpath as an explicitly-handled
>> option.
>> > > Although it doesn't need to handle every possible option, the fact
>> that it
>> > > has RPATH support but doesn't know about -rpath seems like a bug.
>> >
>> >
>> > This could be toolchain dependent. What compiler/linker is SCons using?
>> I
>> > would need to refresh my memory of how the SCons autolink behaviour
>> works,
>> > but each Tool has a different parse setup. There could be a variety of
>> > faults here: wrong tool being assumed by SCons, tool needs to be updated
>> > for new or missing parse options, etc.
>> >
>> > Looks like this issue might be in
>> > src/engine/SCons/Environment.py:do_parse().  It looks like "-rpath" and
>> > "-R" are deprecated features according to the notes. The parse is
>> > expecting "-Wl,R", "-Wl,R," or "-Wl,rpath=" which are all correct.
>>
>> The source I'm looking at only lists -R as deprecated, not -rpath.  In any
>> case, "deprecated" isn't supposed to mean "crash if seen", particularly
>> when users don't necessarily have any control over what someone else
>> decides to put in the pkgconfig data.
>>
>> I found a workaround, which is to use the --libs-only-L and --libs-only-l
>> options to pkg-config instead of --libs, but that's a pretty ugly kludge
>> and also broke something else until I applied it more selectively.
>>
>> > > 2) After passing over the -rpath, it then encounters the
>> /usr/local/lib,
>> > > which (presumably as the default assumption for unknown non-option
>> items)
>> > > it assumes is a file.  But there's already a directory node for it
>> > > (probably as a result of the -L), so the attempt to create a file node
>> > > results in a TypeError exception from the klass mismatch.
>> > >
>> >
>> > I have seen this pop up a few times recently. The case I saw "appeared"
>> to
>> > be related to parts of SCons creating File Entries and then comparing
>> the
>> > abstract entry to the correct subtype and throwing an error. In this
>> case,
>> > SCons should determine that one is a subclass and that the subclass
>> > supersedes the abstract version. Someone would have to look into this
>> > further.
>>
>> In this case it was definitely comparing a directory node to a file node.
>> Indeed, if it doesn't really know whether someting is a file or directory,
>> it would make sense to use something more generic along with a more
>> forgiving comparison, but that's not what's happening here.
>>
>> > > 3) Nothing catches this exception until it gets all the way back to
>> the
>> > > scons top level, which error-exits to the shell.
>> > >
>> >
>> > This error has been assumed critical I believe, but I think that this
>> was
>> > intended for unrelated types...
>>
>> Well, it's not a very friendly way to handle this sort of confusion. :-)
>>
>> Fred Wright
>> _______________________________________________
>> Scons-users mailing list
>> Scons-users at scons.org
>> https://pairlist4.pair.net/mailman/listinfo/scons-users
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20160327/f04e8838/attachment-0001.html>