[pull] master from buildroot:master #269
Merged
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
![pull[bot]](https://avatars.githubusercontent.com/in/12910?s=60&v=4){kind=small}
We are seeing build issues with linux-pam in the autobuilders such as:
md5_crypt.c: In function 'Goodcrypt_md5':
md5_crypt.c:145:13: error: implicit declaration of function 'asprintf'; did you mean 'vsprintf'? [-Wimplicit-function-declaration]
145 | if (asprintf(&passwd, "%s%.*s$%s", magic, sl, sp, buf) < 0)
| ^~~~~~~~
| vsprintf
This is due to the fact that <stdio.h> gets included without
_GNU_SOURCE being defined, and so the prototype of asprintf() is not
accessible, at least with uclibc-ng.
The _GNU_SOURCE definition is properly in linux-pam's config.h, but
config.h doesn't get properly included first everywhere. This issue
has been fixed upstream in the mean time, so we simply backport the
upstream patch.
Fixes:
http://autobuild.buildroot.net/results/49b190b3fbae3cdca4c7a08b3ab5100a937ede9e/
Signed-off-by: Thomas Petazzoni <[email protected]>
Signed-off-by: Julien Olivain <[email protected]>
libxcrypt has been added as a replacement for the libcrypt implementation that was part of glibc, but dropped from glibc starting from version 2.39. However, libxcrypt was made available for all C libraries, and this is unfortunately causing some problems as it can clash with the libcrypt implementation provided by the C library. In particular, linux-pam has been consistently failing with uclibc, in BR2_PER_PACKAGE_DIRECTORIES=y builds, with the following build failure: opasswd.c: In function 'compare_password': opasswd.c:133:27: error: invalid application of 'sizeof' to incomplete type 'struct crypt_data' What happens is relatively tricky, but let's try to break it down: - uclibc-ng install a stub libcrypt.a (no shared variant, as for shared libraries, everything is in libc.so), and crypt.h - libxcrypt installs libcrypt.so.* and crypt.h So there is no "clash" on the library itself, but there is a clash on the header file. Since we're using BR2_PER_PACKAGE_DIRECTORIES=y, when building linux-pam, we are creating the per-package STAGING_DIR by copying the STAGING_DIR of linux-pam dependencies, i.e both the libxcrypt STAGING_DIR and the uclibc-ng STAGING_DIR. But the latter ends up being copied last, which means that at the end of the day, we have in the per-package STAGING_DIR of linux-pam: - The libcrypt.so from libxcrypt - The crypt.h header from uclibc-ng - The libcrypt.a from uclibc-ng When the ./configure script of linux-pam tests whether the library has crypt_r(), it concludes that yes it's available: and indeed libcrypt.so from libxcrypt has it. So it tries to use 'struct crypt_data' and 'crypt_r()', but those are not supported in uClibc-ng, and so cannot be found in the <crypt.h> header. So even if the ./configure script and the linux-pam code has some logic to fallback to crypt() if crypt_r() isn't available, this fallback doesn't trigger because the installed libcrypt.so does have crypt_r(). Basically what happens is that uclibc-ng + libxcrypt is a combo that violates a golden rule of our BR2_PER_PACKAGE_DIRECTORIES=y implementation: packages shouldn't overwrite files from each other. To avoid this situation, we make libxcrypt only installable on glibc. This isn't a problem because as of today, BR2_PACKAGE_LIBXCRYPT is always selected "if BR2_TOOLCHAIN_USES_GLIBC". It should be noted though that the case of an older glibc (which still had its own internal libcrypt) + libxcrypt continues to exist. It's less likely to cause trouble though, as the libcrypt implementations are much more similar. Fixes: http://autobuild.buildroot.net/results/560f66b0311d02dc884732221d6870ae3c38067c/ Note: we do not add a Config.in comment for this glibc dependency, because libxcrypt really is a "replacement" library to fill in the void left by libcrypt's removal from glibc. There isn't realy a point showing "libxcrypt needs a toolchain w/ glibc", because with musl or uclibc-ng, the libcrypt functionality is directly part of the C library. Signed-off-by: Thomas Petazzoni <[email protected]> Signed-off-by: Julien Olivain <[email protected]>
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.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.1)
Can you help keep this open source service alive? 💖 Please sponsor : )