Order of libs with (mis)configured Libs.private #51

New Issue

ariadne · 2013-08-21T09:47:50Z

tonytheodore commented

2013-08-21 09:47:50 +00:00

(Migrated from github.com)

Hi,

This is similar to #33 and #34, though it only happens with a seemingly misconfigured *.pc file. I've stripped down the offending files to:

Name: GraphicsMagick
Requires: libxml-2.0
Libs: -lGraphicsMagick
Libs.private: -llzma -lxml2

Name: libxml-2.0
Requires: liblzma
Libs: -lxml2

Name: liblzma
Libs: -llzma

and the resulting outputs are:

pkgconf GraphicsMagick --libs-only-l --static
-lGraphicsMagick -llzma -lxml2

pkg-config GraphicsMagick --libs-only-l --static
-lGraphicsMagick -llzma -lxml2 -llzma

GraphicsMagick populates Libs.private instead of relying on the traversal of requirements and it's easy enough to fix there, but it would be good if pkgconf could handle this (from the previous issues, it sounds like this should work).

This happens on both current master branch and 0.9.2.

Hi, This is similar to #33 and #34, though it only happens with a seemingly misconfigured *.pc file. I've stripped down the offending files to: ``` Name: GraphicsMagick Requires: libxml-2.0 Libs: -lGraphicsMagick Libs.private: -llzma -lxml2 Name: libxml-2.0 Requires: liblzma Libs: -lxml2 Name: liblzma Libs: -llzma ``` and the resulting outputs are: ``` sh pkgconf GraphicsMagick --libs-only-l --static -lGraphicsMagick -llzma -lxml2 pkg-config GraphicsMagick --libs-only-l --static -lGraphicsMagick -llzma -lxml2 -llzma ``` GraphicsMagick populates Libs.private instead of relying on the traversal of requirements and it's easy enough to fix there, but it would be good if pkgconf could handle this (from the previous issues, it sounds like this should work). This happens on both current master branch and 0.9.2.

ariadne commented

2013-08-23 01:59:51 +00:00

Can you provide output of pkgconf --simulate GraphicsMagick?

Can you provide output of `pkgconf --simulate GraphicsMagick`?

ariadne commented

2013-08-23 02:56:08 +00:00

Actually, this is not a bug in my opinion. Please submit evidence of a real-world build failure caused by this.

What is happening here is that pkgconf is deduplicating the extra flags provided by Libs.private. Beyond this, the ordering of the libs is the same in the pkg-config output, after binutils does a merge-back phase on the linker flags anyway.

pkgconf does a merge-back on the linker flags so that libraries are ordered by number of dependencies beginning from the root, outward. This ensures that all linker dependencies are resolved in proper order and prevents overlinking.

Actually, this is not a bug in my opinion. Please submit evidence of a real-world build failure caused by this. What is happening here is that pkgconf is deduplicating the extra flags provided by Libs.private. Beyond this, the ordering of the libs is the same in the pkg-config output, after binutils does a merge-back phase on the linker flags anyway. pkgconf does a merge-back on the linker flags so that libraries are ordered by number of dependencies beginning from the root, outward. This ensures that all linker dependencies are resolved in proper order and prevents overlinking.

ariadne commented

2013-08-23 03:19:23 +00:00

Oh, I see now. --static should disable merge-back.

Oh, I see now. `--static` should disable merge-back.

tonytheodore commented

2013-08-24 04:21:32 +00:00

(Migrated from github.com)

Great! Thanks for looking at this, that fixes the original issue, but I stripped the files down too much. A similar thing happens when a there are multiple dependencies on the same lib. Issue #52 demonstrates this in a repeatable way.

Sign in to join this conversation.