Bug 178732 - astro/gpsd: TypeError: Tried to lookup Dir '/usr/local/lib' as a File.: *** [do-build] Error code 2
Summary: astro/gpsd: TypeError: Tried to lookup Dir '/usr/local/lib' as a File.: *** [...
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: Normal Affects Only Me
Assignee: Baptiste Daroussin
URL:
Keywords:
Depends on: 209526
Blocks:
  Show dependency treegraph
 
Reported: 2013-05-18 08:40 UTC by Christian A Bryant
Modified: 2018-01-14 21:05 UTC (History)
6 users (show)

See Also:


Attachments
to be dropped into devel/ncurses/files/ (447 bytes, patch)
2015-12-05 16:55 UTC, Christoph Moench-Tegeder
no flags Details | Diff
[patch] improve freebsd rpath usage in devel/ncurses configure (530 bytes, patch)
2016-01-17 07:29 UTC, John Hein
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Christian A Bryant 2013-05-18 08:40:00 UTC
root@tosh12:/usr/ports/astro/gpsd # make install clean
===>  Building for gpsd-3.9
scons: Reading SConscript files ...
Checking if compiler accepts -Wextra ...yes
Checking if compiler accepts -Wall ...yes
Checking if compiler accepts -Wno-uninitialized ...yes
Checking if compiler accepts -Wno-missing-field-initializers ...yes
Checking if compiler accepts -Wcast-align ...yes
Checking if compiler accepts -Wmissing-declarations ...yes
Checking if compiler accepts -Wmissing-prototypes ...yes
Checking if compiler accepts -Wstrict-prototypes ...yes
Checking if compiler accepts -Wpointer-arith ...yes
Checking if compiler accepts -Wreturn-type ...yes
chrpath is not available or use of it has been disabled.
Checking whether the C++ compiler worksyes
Checking for ncurses... no
Checking for ncurses5-config... yes
Checking for libusb-1.0... no
Checking for C library librt... yes
Checking for C library libcap... no
Checking for bluez... no
Checking for C header file sys/timepps.h... yes
You have kernel PPS available.
Checking for C header file linux/can.h... no
You do not have kernel CANbus available.
Checking for C function daemon()... yes
Checking for C function strlcpy()... yes
Checking for C function strlcat()... yes
Checking for C function clock_gettime()... yes
Checking for C function pselect()... yes
Checking for C header file endian.h... no
Checking for C header file sys/endian.h... yes
Checking that xsltproc can make man pages... yes
Altered configuration variables:
mtk3301 = False (default True): MTK-3301 support
nmea2000 = False (default True): NMEA2000/CAN support
bluez = False (default True): BlueZ support for Bluetooth devices
libQgpsmm = False (default True): build QT bindings
chrpath = False (default True): use chrpath to edit library load paths
mandir = man (default share/man): manual pages directory
pkgconfig = libdata/pkgconfig (default lib/pkgconfig): pkgconfig file directory
TypeError: Tried to lookup Dir '/usr/local/lib' as a File.:
  File "/usr/ports/astro/gpsd/work/gpsd-3.9/SConstruct", line 955:
    parse_flags=gpsdlibs + ncurseslibs + ['-lm'])
  File "/usr/local/lib/scons-2.1.0/SCons/Environment.py", line 258:
    return MethodWrapper.__call__(self, target, source, *args, **kw)
  File "/usr/local/lib/scons-2.1.0/SCons/Environment.py", line 222:
    return self.method(*nargs, **kwargs)
  File "/usr/local/lib/scons-2.1.0/SCons/Builder.py", line 631:
    env = env.Override(env_kw)
  File "/usr/local/lib/scons-2.1.0/SCons/Environment.py", line 635:
    if merges: env.MergeFlags(merges)
  File "/usr/local/lib/scons-2.1.0/SCons/Environment.py", line 810:
    args = self.ParseFlags(args)
  File "/usr/local/lib/scons-2.1.0/SCons/Environment.py", line 796:
    do_parse(arg)
  File "/usr/local/lib/scons-2.1.0/SCons/Environment.py", line 670:
    for t in arg: do_parse(t)
  File "/usr/local/lib/scons-2.1.0/SCons/Environment.py", line 726:
    dict['LIBS'].append(self.fs.File(arg))
  File "/usr/local/lib/scons-2.1.0/SCons/Node/FS.py", line 1339:
    return self._lookup(name, directory, File, create)
  File "/usr/local/lib/scons-2.1.0/SCons/Node/FS.py", line 1318:
    return root._lookup_abs(p, fsclass, create)
  File "/usr/local/lib/scons-2.1.0/SCons/Node/FS.py", line 2223:
    result.must_be_same(klass)
  File "/usr/local/lib/scons-2.1.0/SCons/Node/FS.py", line 626:
    (self.__class__.__name__, self.path, klass.__name__))
*** [do-build] Error code 2

Stop in /usr/ports/astro/gpsd.
*** [install] Error code 1

Stop in /usr/ports/astro/gpsd.

Fix: 

Unknown
How-To-Repeat: Step 1: Log into server
Step 2: su
Step 3: cd /usr/ports/astro/gpsd
Step 4: root@tosh12:/usr/ports/astro/gpsd # make install clean
Step 5: Fails
Comment 1 Edwin Groothuis freebsd_committer freebsd_triage 2013-05-19 09:25:47 UTC
Responsible Changed
From-To: freebsd-ports-bugs->glebius

Over to maintainer (via the GNATS Auto Assign Tool)
Comment 2 Carlo Strub freebsd_committer freebsd_triage 2014-09-14 10:29:09 UTC
Is this PR still relevant?
Comment 3 Gleb Smirnoff freebsd_committer freebsd_triage 2014-09-14 10:42:31 UTC
I never achieved to reproduce it.
Comment 4 Christoph Moench-Tegeder freebsd_committer freebsd_triage 2015-12-05 16:54:57 UTC
This issue is reproducable - it's an interaction between gpsd's scons build system and the pkg-config files of devel/ncurses. To put it the other way round, it is _only_ reproducable if you have devel/ncurses installed. I came across this when rebuilding gpsd-3.14 after today's upgrade to ncurses-6.0.

Gory details ahead: ncurses.pc has "-rpath /usr/local/lib" in it's Libs: line. Scons tries to parse the pkgconf output but does not know about "-rpath". OTOH, it expects C compiler flags, not linker flags; and all other .pc-files at hand have "-Wl,-rpath -Wl,/usr/local/lib", so I guess it's really ncurses which is at fault here.

Attached file has to be dropped as devel/ncurses/files/patch-misc__gen-pkgconfig.in. It makes sure ncurses pkgconfig files are in line with all other pkgconfig files, and gpsd finishes scons.

Note there's another patch neccessary to make gpsd build successfully, but as this is more of a ncurses issue than a gpsd issue, I'll submit that in a seperate PR shortly.
Comment 5 Christoph Moench-Tegeder freebsd_committer freebsd_triage 2015-12-05 16:55:24 UTC
Created attachment 163871 [details]
to be dropped into devel/ncurses/files/
Comment 6 Christoph Moench-Tegeder freebsd_committer freebsd_triage 2015-12-05 16:56:10 UTC
Cc'ing devel/ncurses maintainer
Comment 7 Baptiste Daroussin freebsd_committer freebsd_triage 2015-12-05 17:07:22 UTC
Actually the bug in is scons because the -rpath is passed when asking for libs while here scons should request cflags in that case.

So either scons or the sconsfile in gpsd has to be fixed imho not ncurses.

While here reopen to track it
Comment 8 Christoph Moench-Tegeder freebsd_committer freebsd_triage 2015-12-05 17:23:34 UTC
There's two points against that:

- all other available .pc-files use the -Wl construct - that is, it's silently (I couldn't find any explicit documentation) assumed that $CC is used for linking, so that all linker arguments have to be in CFLAGS format. Even the pkg-config guide assumes that the pkgconfig output will be used on the cc command line: http://people.freedesktop.org/~dbn/pkg-config-guide.html#faq FAQ 1 - but there's no clear word on wether to use ld(1) or cc(1) style arguments.

- scons itself does ignore "-rpath" by design. Deep down in it's Environment.py a comment states (ll.691):
#[...] It particular, if the
# flag is not known to occur in a config script and there's a way
# of passing the flag to the right place (by wrapping it in a -W
# flag, for example) we don't check for it.
Comment 9 John Hein 2016-01-17 07:29:01 UTC
Created attachment 165695 [details]
[patch] improve freebsd rpath usage in devel/ncurses configure

The cases that use ld(1) directly are vanishingly small, so having '-Wl,-rpath,' in the .pc file rather than '-rpath ' seems far better - for any software using pkg-config --libs.

While scons could be fixed to convert any '-rpath foo' it sees to '-Wl,-rpath,foo' (especially since smart_link() in link.py invokes cc by default (and never ld unless the user perversely defines CC=ld), it's a fact of life that it doesn't do such a conversion right now.

So I vote we patch ncurses and move on so gpsd is fixed when the ncurses package is installed.

Attached is an alternate patch that fixes the freebsd case in the ncurses configure script - it may be more palatable and could be fed upstream to ncurses.

It's more correct than just -rpath since the vast majority of possible consumers of 'pkg-config --libs' flags will be linkers invoked by 'cc' or 'c++'.  And the bare -rpath will cause those to fail, not just those wrapped by scons.  How often do we see a port invoke ld(1) directly to do the linking?

Maybe scons could be convinced to improve their arg parsing as well (convert any '-rpath foo' it might see to Wl,-rpath,foo), but that doesn't solve the issue for any non-scons user of the 'pkg-config --libs ncurses' flags.  Seeing as there have been likely few other reported failures due to this issue, the number is probably low, but we should fix ncurses for freebsd, IMO.
Comment 10 John Hein 2016-01-18 04:51:55 UTC
poudriere build of scons + ncurses (with attachment 165695 [details]) + gpsd passed.
The same ncurses + attachment 165695 [details] was used to build lang/python27 & lang/python34 in the poudriere jail as well - also passed.
Comment 11 John Hein 2016-02-14 18:41:37 UTC
Any chance we can fix ncurses (per the patch in comment 9)?  This issue has been hanging around forever.  ncurses is the only port that I have seen that installs a .pc file that uses bare -rpath rather than -Wl,-rpath.

Yes, gcc on freebsd (but not linux) does accept a bare -rpath (as does clang), but -Wl,-rpath is generally preferred.  Even the support for -rpath on gcc/freebsd doesn't document -rpath in the man pages or info pages (maybe it did at some point in the distant past?).

No one has come forward with a patch to scons to make it somehow accept bare -rpath (maybe convert it to -Wl,-rpath??).  And the comment in scons seems to indicate the burden is on the user to not pass in things that should be wrapped by -Wl.

I'm sure scons could be improved here (at least a better error message), but considering the expectation of the usage of the linker flags in most .pc files (that it is called from cc(1), not ld(1)), I think there's a case to made to update the ncurses configure script on freebsd such that it is consistent with the preference for -Wl,-rpath.
Comment 12 John Hein 2016-02-14 20:16:54 UTC
Similar patch from comment 9 submitted upstream to ncurses:

http://lists.gnu.org/archive/html/bug-ncurses/2016-02/msg00006.html
Comment 13 Baptiste Daroussin freebsd_committer freebsd_triage 2016-02-18 07:17:54 UTC
(In reply to John Hein from comment #11)
Yes it makes sense to make such patch in ncurses and it makes it consistent with other plateforms (it uses that on linux or netbsd for instance)

As soon as I have enough time I will commit this.

Thanks!

Sorry for the delay
Comment 14 John Hein 2016-02-21 21:24:04 UTC
(In reply to John Hein from comment #12)

Change to -Wl,-rpath for FreeBSD applied upstream (ncurses-6.0-20160220):

http://lists.gnu.org/archive/html/bug-ncurses/2016-02/msg00009.html
Comment 15 John Hein 2016-05-06 00:06:24 UTC
(In reply to Baptiste Daroussin from comment #13)
Baptiste, should I open a new ncurses bug for the ncurses patch here?
Comment 16 John Hein 2016-05-15 19:35:52 UTC
(In reply to John Hein from comment #15)
Separate bug opened for the -Wl,-rpath fix to devel/ncurses so this doesn't get lost in a bug report for a different port:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209526
Comment 17 John Hein 2016-12-11 21:08:55 UTC
This can be closed now.  The ncurses port was fix per bug 209526.
Comment 18 John Hein 2017-01-07 00:14:38 UTC
Comment on attachment 165695 [details]
[patch] improve freebsd rpath usage in devel/ncurses configure

This patch was applied a while ago to the ncurses port (per bug 209526) - mark obsolete.
Comment 19 John Hein 2017-01-07 00:16:21 UTC
(In reply to John Hein from comment #17)

In case a bug editor comes along, this should be closed as "FIXED".
Comment 20 Walter Schwarzenfeld 2018-01-12 01:57:07 UTC
See previous message. I think this could closed.
Comment 21 Christoph Moench-Tegeder freebsd_committer freebsd_triage 2018-01-14 21:05:59 UTC
ok, I heard you :)