[Scons-users] Problems with ParseFlags()

[William Blevins]

Please always specify your version of SCons and python. Other inline
comments below.

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.


>
> 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.


>
> 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...


>
> In addition:
>
> 4) Even when running with --debug=pdb, the uncaught exception exits to the
> shell, rather than going to pdb in a state where pdb.pm() can be used to
> examine the exception context.
>
> Also, it's annoying to have to specify the full path to SConstruct in
> order to set breakpoints in it.  This is mainly pdb's fault; I don't know
> if there's an easy way for scons to add the SConstruct directory to pdb's
> list of search paths.
>
> 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/a9a5b249/attachment.html>