Remove -lm -ldl from hdf5.pc on macOS
#4616
Conversation
Motivation ---------- Prior to this commit, the Libs.private entry within hdf5.pc contain the ``-lm`` and ``-ldl`` flags on macOS. Becuase macOS (for at least a number of recent releases) doesn't specify actually contain these libraries, this means that passing the flags produced by ``pkg-config --static --libs hdf5`` will produce linker errors on macOS. The contents of these particular libraries are instead all consolidated within a single system library. The Solution ------------ It turns out that this issue originates from some "magic" that CMake does to removes these flags from all calls to the linker on macOS. This "magic" seems to cause the built-in logic for checking for the existence of these libraries to falsely report that the libraries exist on macOS. These false positives propagate to the contents of the contents of hdf5.pc. At the same time, this same "magic" seems to prevent linker-errors during the actual compilation of hdf5. Concerns -------- I think that much older versions of macOS may have actually provided the "m" and "dl" libraries. If that is the case, then my fix may break builds on these versions of macOS... I'm not really sure when this transition occured.
|
I am currently looking into this and fixing a number of issues - are you including any compression libs? Because they are incorrect for static linking. Also, I believe the dl library shouldn't be in the link line for static anyway. |
Yeah I was -- I noticed that was an issue. I should have been more clear in the PR. For some added context, I was testing out a pkg-config file that I was thinking about providing for a downstream library (that internally employs hdf5) using the copy of hdf5 installed with homebrew. While doing this, I saw that there were linker errors associated with After making the changes for the PR, I noticed that the revised pkg-config file still complains about Bottom line: this PR is really just a partial fix (I figured something could be more useful that just opening an issue). I should have really been more clear about that in the PR description. Sorry about that! If you're working on this stuff, feel free to close my PR. At the end of the day, I've decided against relying upon this, anyways, since most of my libraries' users are on Linux (and the Libs.private line is stripped out of the hdf5.pc file shipped in the commonly used hdf5 Debian package) |
|
Closing because #4613 will cover issue. |
Motivation
Prior to this commit, the Libs.private entry within hdf5.pc contain the
-lmand-ldlflags on macOS. Becuase macOS (for at least a number of recent releases) doesn't specify actually contain these libraries, this means that passing the flags produced bypkg-config --static --libs hdf5will produce linker errors on macOS. The contents of these particular libraries are instead all consolidated within a single system library.
The Solution
It turns out that this issue originates from some "magic" that CMake does to removes these flags from all calls to the linker on macOS. This "magic" seems to cause the built-in logic for checking for the existence of these libraries to falsely report that the libraries exist on macOS. These false positives propagate to the contents of the contents of hdf5.pc. At the same time, this same "magic" seems to prevent linker-errors during the actual compilation of hdf5.
Concerns
I think that much older versions of macOS may have actually provided the "m" and "dl" libraries. If that is the case, then my fix may break builds on these versions of macOS...
I'm not really sure when/if this transition occurred and I don't know how to figure this out. If this is a serious concern, I could try to figure this out. (With that said, I don't have a ton of bandwidth for this. If there isn't an easy answer, we might just need to close this PR)