[Scons-users] Problems with ParseFlags()

[William Blevins]

Any chance of a File/Dir exception stack trace from "scons
--debug=stacktrace"?

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/6708d947/attachment.html>