aboutsummaryrefslogtreecommitdiff
path: root/src/Makefile.crc32c.include
AgeCommit message (Collapse)Author
2024-08-30build: Remove Autotools-based build systemHennadii Stepanov
2022-04-26build: Create .la library for crc32cCarl Dong
Libtool will yell at you if you try to link a shared library against static ones. This change creates a libtool archive library for crc32c and allows a shared library to be linked against it portably. Also specify -static in both: - ..._la_CXXFLAGS so that libtool will avoid building two versions of each object (one PIC, one non-PIC). We just need the one that is suitable for static linking. - ..._la_LDFLAGS so that libtool will create a static library. [META] This change is done in preparation for a future commit where we link the libbitcoinkernel library against this one.
2022-04-11build: Remove vestigial LIBLEVELDB_SSE42Carl Dong
- LIBLEVELDB_SSE42_INT was defined, but never referenced anywhere - LIBLEVELDB_SSE42 is referenced, but never defined anywhere Apparently leveldb used to have platform-specific crc32 code before it got split off into a separate lib.
2021-09-24build: remove support for weak linking getauxval()fanquake
It was [pointed out in #23030](https://github.com/bitcoin/bitcoin/pull/23030#issuecomment-922893367) that we might be able to get rid of our weak linking of [`getauxval()`](https://man7.org/linux/man-pages/man3/getauxval.3.html) (`HAVE_WEAK_GETAUXVAL`) entirely, with only Android being a potential holdout: > I wonder if it's time to get rid of HAVE_WEAK_GETAUXVAL. I think it's confusing. Either we build against a C library that has this functionality, or not. We don't do this weak linking thing for any other symbols and recently got rid of the other glibc backwards compatibility stuff. > Unless there is still a current platform that really needs it (Android?), I'd prefer to remove it from the build system, it has caused enough issues. After looking at Android further, it would seem that given we are moving to using `std::filesystem`, which [requires NDK version 22 and later](https://github.com/android/ndk/wiki/Changelog-r22), and `getauxval` has been available in the since [API version 18](https://developer.android.com/ndk/guides/cpu-features#features_using_libcs_getauxval3), that shouldn't really be an issue. Support for API levels < 19 will be dropped with the NDK 24 release, and according to [one website](https://apilevels.com/), supporting API level 18+ will cover ~99% of devices. Note that in the CI we currently build with NDK version 22 and API level 28. The other change in this PR is removing the include of headers for ARM intrinsics, from the check for strong `getauxval()` support in configure, as they shouldn't be needed. Including these headers also meant that the check would basically only succeed when building for ARM. This would be an issue if we remove weak linking, as we wouldn't detect `getauxval()` as supported on other platforms. Note that we also use `getauxval()` in our RNG when it's available. I've checked that with these changes we detect support for strong `getauxval()` on Alpine (muslibc). On Linux, previously we'd be detecting support for weak getauxval(), now we detect strong support. Note that we already require glibc 2.17, and `getauxval()` was introduced in `2.16`. This is an alternative / supersedes #23030.
2020-12-08build: Update crc32c subtreeMarcoFalke
2020-01-28build: CRC32C build system integrationWladimir J. van der Laan