[Scons-users] Problems with ParseFlags()

Sun Mar 27 15:54:59 EDT 2016

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/5bacd99a/attachment-0001.html>