[Scons-users] Problems with ParseFlags()

[Fred Wright]

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