Bug 58363 - `pkg-config --libs` should swallow -L/lib like it does with -L/usr/lib
Summary: `pkg-config --libs` should swallow -L/lib like it does with -L/usr/lib
Status: RESOLVED FIXED
Alias: None
Product: pkg-config
Classification: Unclassified
Component: src (show other bugs)
Version: unspecified
Hardware: All All
: medium normal
Assignee: Dan Nicholson
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-12-16 13:28 UTC by Samuli Suominen
Modified: 2012-12-19 15:33 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Add root /lib* directories to the default -L paths (1.29 KB, patch)
2012-12-16 17:29 UTC, Dan Nicholson
Details | Splinter Review

Description Samuli Suominen 2012-12-16 13:28:20 UTC
This is coming from: http://bugs.gentoo.org/445796

I've noticed, for a long time now, that pkg-config doesn't print -L flags for system path(s) like /usr/lib with --libs argument

However, it still prints -L/lib and doesn't act like it does for -L/usr/lib

Quoting Mike Frysinger from the downstream bug:

"pkg-config should automatically skip it.  it has logic internally to do this for /usr/lib and /usr/lib64 and ..."

Please read the downstream bug and you will notice this oddity is actually causing issues.

Thanks,
Samuli
Comment 1 Dan Nicholson 2012-12-16 17:29:07 UTC
Created attachment 71591 [details] [review]
Add root /lib* directories to the default -L paths

Avoids outputting -L/lib, which the linker will search in implicitly like -L/usr/lib.

Freedesktop #58363 (https://bugs.freedesktop.org/show_bug.cgi?id=58363)
Comment 2 Dan Nicholson 2012-12-16 17:35:35 UTC
I can't believe I never noticed that before. Does the attached patch help?

On the other hand, I'm a little wary of encoding this behavior by default since I'm only familiar with gcc, which does contain /lib in it's default. Gentoo could easily just configure their pkg-config with --with-system-library-path=/usr/lib:/lib or whatever you want to tune it to.

What do you guys think? Mike?
Comment 3 Samuli Suominen 2012-12-16 17:43:00 UTC
I'm waiting for a comment from other Gentoo developers (made a query on IRC) and if nobody is seeing a problem this would introduce, I'm going to apply the patch for testing with a incremental revision bumped package tomorrow.

I'd rather see the configure.ac patched like you just did, than pass the ./configure flag manually, it just makes sense to have by default there.
Comment 4 Dan Nicholson 2012-12-16 17:46:41 UTC
(In reply to comment #3)
> I'd rather see the configure.ac patched like you just did, than pass the
> ./configure flag manually, it just makes sense to have by default there.

Right, I'm questioning whether it makes sense that is the default for everybody. For GCC/GNU LD, yeah definitely this makes sense. But does it for every toolchain? I suppose the alternate toolchains would be more in the minority and the onus would be on those users to configure with their correct --with-system-library-path.
Comment 5 Mike Frysinger 2012-12-16 21:49:32 UTC
(In reply to comment #4)

if pkg-config is doing it for /usr/lib type paths, then it makes sense for /lib type paths too.  i don't think the underlying toolchain matters.

however, the proposed patch isn't complete :/.  to be fair, the existing code isn't complete either.  it misses standard ABI dirs like lib32 and libx32.

maybe the existing code could read:

pc_lib_sfx=$(echo "$libdir" | sed 's:.*/lib::')
case "$pc_lib_sfx" in
*/*|"")
  system_library_path="/usr/lib:/lib"
  ;;
*)
  system_library_path="/usr/lib$pc_lib_sfx:/lib$pc_lib_sfx:/usr/lib:/lib"
  ;;
esac
Comment 6 Dan Nicholson 2012-12-19 15:33:04 UTC
(In reply to comment #5)
> 
> pc_lib_sfx=$(echo "$libdir" | sed 's:.*/lib::')
> case "$pc_lib_sfx" in
> */*|"")
>   system_library_path="/usr/lib:/lib"
>   ;;
> *)
>   system_library_path="/usr/lib$pc_lib_sfx:/lib$pc_lib_sfx:/usr/lib:/lib"
>   ;;
> esac

Yep, good call. I added this as a second commit and have now pushed them both. The bug is fixed in 72e1346, and the addition to handle various ABIs is in 4dac402 authored by you.

Thanks!


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.