Fix unconditional uses of Linux-specific extensions #2812
Merged
+56
−17
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
pmatilai
changed the title
pmatilai
changed the title
pmatilai
force-pushed
the
portability-pr
branch
2 times, most recently
from
7a30644
to
bbbf6b0
Compare
Conditionalize elfdeps build on libelf availability.
We missed the use of this non-standard function on review. rpmsort needs to be fixed to not rely on GNU extensions but in the meanwhile we need to check for that function and disable if not present.
This regressed when we axed our internal glob copy in commit 66fa46c. Luckily GLOB_ONLYDIR is only an optimization so we can just skip it if not available.
Should've been in commit 04d49fb where basename() usage was introduced. And because the standard version of basename() has non-const argument, we run into rpm2archive using non-standard const argument to main(), because popt got it wrong. Move the const-cast to the popt invocation for consistency with the other codebase. Suggested-by: Mark Dascher <mark@papertrail.com>
Yet more rather obvious fallout from the cmake transition. It's strange these don't fail the build on Linux. Suggested-by: Mark Dascher <mark@papertrail.com>
I clearly remember testing the behavior wrt these and concluding that the cmake exported interface syntax doesn't require conditionalizing. Clearly it does though, so dunno what I was supposed to have tested back then. Suggested-by: Mark Dascher <mark@papertrail.com>
pmatilai
force-pushed
the
portability-pr
branch
from
bbbf6b0
to
a5e9e72
Compare
pmatilai
force-pushed
the
portability-pr
branch
from
ccb6cb0
to
8b219fe
Compare
We checked for libintl in the top-level CMakeLists.txt but then never used it for anything. This only ever worked on glibc where this all is bundled in. Unfortunately Intl only becomes an importable target in cmake >= 3.20 which is too new for us to rely on for now. Python bindings are omitted here because we don't have any translated messages in there. Whether we should is another topic.
This is mildly annoying, librpm users don't need to link to popt but this one include in rpmcli.h (that most API users wont even use) forces a public dependency on it. Another possibility could be splitting out the "cli" part of librpm one way or another, but that doesn't seem worth all the trouble it would be.
pmatilai
force-pushed
the
portability-pr
branch
from
8b219fe
to
0adda3d
Compare
|
As per #2807 (comment) mission accomplished. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Should fix the issues brought up in #2807 - portability rot that inevitably happens when you only build on one target.