[Scons-users] Problems with ParseFlags()

Sun Mar 27 08:53:34 EDT 2016

The User Guide examples use both "--libs" and "--cflags" so I'm not sure if
you are expected to use both or not. It isn't explicit.

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

> 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/63a0a270/attachment-0001.html>