[Scons-users] Problems with ParseFlags()

Sun Mar 27 16:02:05 EDT 2016

I read some more about pkg-config files and I think my assumption was
completely wrong since the two options are just different variable outputs.

Learn something new every day ;(

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

> Fred,
>
> I don't know all the expected output strings from pkg-config, but GNU GCC
> Toolkit can do linking also; thus, it would make sense if "--cflags" would
> also return gcc formatted linking options.
>
> Your original example:
>
>> $ pkg-config --libs ncurses
>> -L/usr/local/lib -rpath /usr/local/lib  -lncurses -ltinfo
>>
>
> I imagine if you use "--cflags" option instead you will get something like
>
>> $ pkg-config --cflags ncurses
>> -L/usr/local/lib -Wl,-rpath=/usr/local/lib -lncurses -ltinfo
>>
> which SCons ParseConfig should handle or at least claims to handle.
>
> If my understanding here is wrong, then I apologize.
>
> V/R,
> William
>
> On Sun, Mar 27, 2016 at 8:10 PM, Fred Wright <fw at fwright.net> wrote:
>
>>
>> First collecting the responses and removing most of the quoted text.
>>
>> On Sun, 27 Mar 2016, William Blevins wrote:
>>
>> > Oh! Do --cflags instead. SCons expects compiler flags and not linker
>> flags
>> > :)
>>
>> I believe it handles both.
>>
>> > I just reviewed the pkg-config man page. Try "--cflags". I should look
>> at
>> > the SCons User Guide and see what it says now.
>>
>> The actual case uses both, but I left out the --cflags in the interests of
>> brevity, given that the compiler flags weren't relevant to the problem.
>>
>> In the real case, ParseFlags() is fed the combined compile/link flags,
>> and I believe the idea is that it parcels out the recognized flags into
>> the appropriate categories, with anything unrecognized dumped into
>> CCFLAGS.
>>
>> On Sun, 27 Mar 2016, William Blevins wrote:
>>
>> > Any chance of a File/Dir exception stack trace from "scons
>> > --debug=stacktrace"?
>>
>> I could arrange that, but what additional information would it provide
>> that I haven't already posted?  It was definitely trying to create a file
>> node when a directory node of that name already existed, and that's
>> certainly the expected behavior when -rpath isn't recognized.  The only
>> thing that isn't definitely known is how the directory node got created,
>> but I don't think that's especially relevant.
>>
>> Due to the poor exception handling in --debug=pdb mode, I debugged it by
>> modifying SConstruct to wrap a try/except block around the failing call,
>> and then set a breakpoint in the except clause.
>>
>> On Sun, 27 Mar 2016, William Blevins wrote:
>>
>> > 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.
>>
>> It depends on what you're feeding them to.  If you're running just a
>> compile, then --cflags is appropriate,  If you're running just a link,
>> then --libs is appropriate.  If you're doing combined compiling/linking,
>> then you need both.
>>
>> On Sun, 27 Mar 2016, Dirk Bächle wrote:
>>
>> > here are two links to discussions of this issue:
>> >
>> >    https://reviews.freebsd.org/D5129
>> >    https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=178732
>> >
>> > , which make me wonder whether SCons should bother about "-rpath" at
>> > all. I see that there might be room for improvement regarding the
>> > exception handling and error messaging for ParseFlags()*, but I don't
>> > see the missing "-rpath" option as a bug...it's simply not implemented.
>> > And for good reasons as it looks... ;)
>>
>> The first link seems to involve confusion over whether the linker was
>> being run directly or via the compile front end.  And the "fix" was to
>> change *from* the -Wl,rpath= construct that SCons *does* recognize *to*
>> the -rpath construct that it *doesn't*.  So that "fix" is the trigger for
>> the problem I'm seeing.
>>
>> The second link is about precisely the problem I'm seeing, except that it
>> takes the approach of trying to get it fixed in ncurses, but it's
>> incorrect in assuming that ncurses is the only package with the issue.
>> It also appears that the "fix" is just changing it back to the way it was
>> when it was causing the problem reported in the first link.
>>
>> BTW, even just in the GPSD case alone, the same issue exists with the
>> tinfo package as well as ncurses.  The pkgconfig data for FreeBSD ncurses
>> specifies including tinfo, but apparently that's not true on all
>> platforms, so GPSD's SConstruct applies pkgconfig data for both.
>>
>> On Sun, 27 Mar 2016, William Blevins wrote:
>>
>> > Dirk,
>> >
>> > I'm not sure that this is a bug. It may just be that the SCons User's
>> Guide
>> > is not specific about the assumptions of ParseConfig implementation.
>> >
>> > It appears that SCons ParseConfig is expecting results from pkg-config
>> in
>> > the form given by "--cflags" and not "--libs" (at least in terms of
>> rpath).
>> > It may be that BOTH options are required based on the SCons User's Guide
>> > examples, but we should really cross reference the code in
>> > src/engine/SCons/Environment.py:do_parse against known gcc/g++ flags vs
>> ld
>> > flags to guarantee that this is a consistent assumption and update SCons
>> > User's Guide documentation respectively.
>>
>> On Sun, 27 Mar 2016, Dirk Bächle wrote:
>>
>> > William,
>> >
>> > On 27.03.2016 16:19, William Blevins wrote:
>> > > Dirk,
>> > >
>> > > I'm not sure that this is a bug. It may just be that the SCons User's
>> > > Guide is not specific about the assumptions of ParseConfig
>> > > implementation.
>> > >
>> >
>> > the documentation of ParseFlags is specific enough for this case in my
>> opinion:
>> >
>> >    "[...] Any other strings not associated with options are assumed to
>> > be the names of libraries and added to the $LIBS construction variable.
>> > [...]"
>> >
>> > There is no need to be specific about whether "--cflags" or "--libs"
>> > should be used when calling "pkg_config". The listed options/flags are
>> > supported and that's it. Note, how ParseFlags also doesn't require you
>> > to call "pkg_config"...the provided flags can come from anywhere...
>>
>> The issue here is that the -rpath argument is a library *directory*, not a
>> library *file*, and "assumed to be names of libraries" is invalid.  And
>> aside from the file vs. directory issue, it should really be adding the
>> argument to RPATH, though I don't think that actually matters in this
>> particular case.
>>
>> On Sun, 27 Mar 2016, William Blevins wrote:
>>
>> > Do you have a link to the specification for the options that ParseConfig
>> > needs to support?
>>
>> I don't know about a link, but I did notice that the FreeBSD compiler
>> doesn't list -rpath in the usage text but does accept it.  This is:
>>
>> $ cc --version
>> FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
>> Target: x86_64-unknown-freebsd10.1
>> Thread model: posix
>>
>> The "accept but don't advertise" behavior may be an indication of
>> deprecation, but I don't see that there's a downside of handling -rpath in
>> ParseFlags() unless there's some toolchain that uses a flag of that name
>> for a different purpose (other than general bloat of the elif chain, but
>> that's largely unavoidable).
>>
>> On Sun, 27 Mar 2016, Dirk Bächle wrote:
>>
>> > On 27.03.2016 17:03, William Blevins wrote:
>> > > Do you have a link to the specification for the options that
>> ParseConfig needs to support?
>> > >
>> >
>> > Again, the ParseFlags() documentation lists the supported flags...I'm
>> > not sure of this counts as "specification", but it makes the expected
>> > behaviour of the method pretty obvious from my angle. ;)
>>
>> Well there's expected behavior, and then there's desired behavior. :-)
>>
>> On Sun, 27 Mar 2016, William Blevins wrote:
>>
>> > Dirk,
>> >
>> > I must not understand then.
>> >
>> > SCons ParseFlags appears to support the items in the documentation and
>> > "-rpath" is not included:
>> > http://scons.org/doc/HTML/scons-man.html#f-ParseFlags. I could see
>> that it
>> > is a feature enhancement possibly? The man page specifically states
>> "Parses
>> > one or more strings containing typical command-line flags for GCC tool
>> > chains" as the first line which implies the options from pkg-config as
>> > given by "--cflags" which are GCC specific versus "--libs" which is LD
>> > specific: http://linux.die.net/man/1/pkg-config. This implies that the
>> > User's Guide example may not be correct since "--libs" format may not be
>> > supported, so we should be explicit.
>>
>> No, --libs isn't a different format, it's just different information.
>> It's flags related to linking passed in the appropriate form for running
>> the linker via the compiler.  If --libs didn't work, zillions of things
>> would be broken.
>>
>> The Internet Robustness Principle states "be liberal in what you accept,
>> and conservative in what you generate".  In this scenario, both the
>> ncurses pkgconfig data and SCons are failing to follow it.
>>
>> 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/fdf766e1/attachment.html>