[Scons-users] Problems with ParseFlags()

[William Blevins]

Inline

On Sun, Mar 27, 2016 at 2:45 AM, William Blevins <wblevins001 at gmail.com>
wrote:

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

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.


>
>
>>
>> 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/002e3cc5/attachment.html>