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.
Hello again:
We have various build targets with different archs, C libraries, etc. Most of them use Musl, but one of the ARM boards this is targeted for actually does use traditional glibc. Everything I add also has to work for our 32- and 64-bit simulation environments as well.
These are the cross-compile targets I'm working with:
There are 2 commits here.
The first commit addresses the usage of pthread NP:
In applying the same kind of Musl patch for 'libnetconf2', CESNET/libnetconf2@153fe40 , I noticed that it actually doesn't work.
check_function_exists(pthread_rwlockattr_setkind_np HAVE_PTHREAD_RWLOCKATTR_SETKIND_NP)
returns false / 'not found' on that arm-glibc target, which definitely does have it in that toolchain's "pthread.h" file.So I ended up writing a patch for 'IPFIXcol2' that uses the slightly different CMake
check_symbol_exists
, which is actually recommended as a replacement by CMake. See note at the bottom of their docs here: https://cmake.org/cmake/help/latest/module/CheckFunctionExists.htmlYou might want to do a similar change in your 'libnetconf2'
arm-glibc target now:
Notice it adds
-DHAVE_PTHREAD_RWLOCKATTR_SETKIND_NP
to CFLAGS. I don't know if this was the best way to do it or not.x86_64-musl target now:
The second commit addresses the usage of
strerror_r
:From manpage of 'strerror' group: https://man7.org/linux/man-pages/man3/strerror.3.html There are 2 signatures of
strerror_r
: XSI and GNU. Musl does not do any GNU extensions, so it only provides the XSI signature returning anint
.strerror_r
is considered non-portable and deprecated anyways, so replace withstrerror_l
."libnl" did something similar: https://lists.infradead.org/pipermail/libnl/2016-August/002196.html
With these 2 commits, I can successfully build for all my targets, and I'll consider that it fixes #34