| Message ID | 1464722725.2379.62.camel@trentalancia.net |
|---|---|
| State | New |
| Headers | show |
On 31 May 2016 21:25, Guido Trentalancia wrote: > When configuring and building GNU libc using the Mozilla NSS library > for cryptography (--enable-nss-crypt option), also include the > NSPR header files along with the Mozilla NSS library header files. > > Finally, when running the check-local-headers test, ignore the > Mozilla NSPR library header files (used by the Mozilla NSS library) > as otherwise false positives (FAIL) are obtained. imo, we should switch to pkg-config, and then probe nss via that. then we don't have to know or care about nspr requirements. -mike
On 06/11/2016 08:04 AM, Mike Frysinger wrote: > On 31 May 2016 21:25, Guido Trentalancia wrote: >> When configuring and building GNU libc using the Mozilla NSS library >> for cryptography (--enable-nss-crypt option), also include the >> NSPR header files along with the Mozilla NSS library header files. >> >> Finally, when running the check-local-headers test, ignore the >> Mozilla NSPR library header files (used by the Mozilla NSS library) >> as otherwise false positives (FAIL) are obtained. > > imo, we should switch to pkg-config, and then probe nss via that. > then we don't have to know or care about nspr requirements. Isn't using pkg-config in a GNU project a bit tricky? In any case, Mozilla does not publish pkg-config data as far as I can see, and downstreams probably vary in what they do. For example, Fedora does not provide pkg-config data for libfreebl at all. You can link against NSS, but then you also get libdl and libpthread, which we do not want as dependencies of libgcrypt. Florian
On 11 Jun 2016 09:12, Florian Weimer wrote: > On 06/11/2016 08:04 AM, Mike Frysinger wrote: > > On 31 May 2016 21:25, Guido Trentalancia wrote: > >> When configuring and building GNU libc using the Mozilla NSS library > >> for cryptography (--enable-nss-crypt option), also include the > >> NSPR header files along with the Mozilla NSS library header files. > >> > >> Finally, when running the check-local-headers test, ignore the > >> Mozilla NSPR library header files (used by the Mozilla NSS library) > >> as otherwise false positives (FAIL) are obtained. > > > > imo, we should switch to pkg-config, and then probe nss via that. > > then we don't have to know or care about nspr requirements. > > Isn't using pkg-config in a GNU project a bit tricky? i don't see why it would be. it's pretty much defacto now for any reasonable library. GNOME, a GNU project, is heavily invested in it. > In any case, Mozilla does not publish pkg-config data as far as I can > see, and downstreams probably vary in what they do. For example, Fedora > does not provide pkg-config data for libfreebl at all. sorry, i thought the pc file was from upstream. then again, i'll note that the nss-config script isn't upstream either, so we're in the same situation: we're left with whatever distros have done. > You can link > against NSS, but then you also get libdl and libpthread, which we do not > want as dependencies of libgcrypt. i'm not sure what you're saying here. `pkg-config --libs nss` doesn't pull in any of those libs. and here we only care about what compiler settings are exposed by `pkg-config --cflags nss`. -mike
On 06/11/2016 10:02 AM, Mike Frysinger wrote: >> Isn't using pkg-config in a GNU project a bit tricky? > > i don't see why it would be. it's pretty much defacto now for any > reasonable library. GNOME, a GNU project, is heavily invested in > it. glibc doesn't provide pkg-config data, either. :-/ (You'd need it for statically linking libcrypt when using NSS. Might also help with the libpthread.a situation.) >> In any case, Mozilla does not publish pkg-config data as far as I can >> see, and downstreams probably vary in what they do. For example, Fedora >> does not provide pkg-config data for libfreebl at all. > > sorry, i thought the pc file was from upstream. then again, i'll note > that the nss-config script isn't upstream either, so we're in the same > situation: we're left with whatever distros have done. Oh. >> You can link >> against NSS, but then you also get libdl and libpthread, which we do not >> want as dependencies of libgcrypt. > > i'm not sure what you're saying here. `pkg-config --libs nss` doesn't > pull in any of those libs. I get this: -lssl3 -lsmime3 -lnss3 -lnssutil3 -lplds4 -lplc4 -lnspr4 -lpthread -ldl And if freebl needs nspr headers, it may pull in libnspr as well, which depends on libpthread. I do not have a strong opinion on this matter. It's messy, so whatever works is okay. But please add a test which does something like dlopen (LIBPTHREAD_SO, RTLD_LAZY | RTLD_NOLOAD) and check that it returns NULL after linking against libcrypt (and using the crypt function). Thanks, Florian
Hello Mike. On Sat, 11/06/2016 at 02.04 -0400, Mike Frysinger wrote: > On 31 May 2016 21:25, Guido Trentalancia wrote: > > When configuring and building GNU libc using the Mozilla NSS > > library > > for cryptography (--enable-nss-crypt option), also include the > > NSPR header files along with the Mozilla NSS library header files. > > > > Finally, when running the check-local-headers test, ignore the > > Mozilla NSPR library header files (used by the Mozilla NSS library) > > as otherwise false positives (FAIL) are obtained. > > imo, we should switch to pkg-config, and then probe nss via that. > then we don't have to know or care about nspr requirements. > -mike Such approach suffers the same problem as the {nss,nspr}-config scripts: you need to use pkg-config data from both NSS *and* NSPR in order to get all the needed header files' paths. So, it won't bring any added benefit, at the expense of increased complexity: not advisable as a first choice in my opinion, perhaps only as a fall-back choice if {nss,nspr}-config scripts are not available on the system... Regards, Guido
On 06/11/2016 01:55 PM, Guido Trentalancia wrote: > Such approach suffers the same problem as the {nss,nspr}-config > scripts: you need to use pkg-config data from both NSS *and* NSPR in > order to get all the needed header files' paths. This shouldn't be a problem because pkg-config knows about dependencies and will reflect their requirements in the generated command lines. If it does not, it's a bug in the distribution-provided .pc files. The larger problem is that we do not particularly care about nss, we want freebl, and at least Fedora doesn't provide a separate .pc file for that. I suppose I could have that fixed for Fedora, but I don't know how painful the process is for other distributions. Florian
On 11 Jun 2016 11:06, Florian Weimer wrote: > On 06/11/2016 10:02 AM, Mike Frysinger wrote: > >> Isn't using pkg-config in a GNU project a bit tricky? > > > > i don't see why it would be. it's pretty much defacto now for any > > reasonable library. GNOME, a GNU project, is heavily invested in > > it. > > glibc doesn't provide pkg-config data, either. :-/ > > (You'd need it for statically linking libcrypt when using NSS. Might > also help with the libpthread.a situation.) true. i wouldn't be against adding it since on our side, the overhead is low -- we just generate text files at configure time and install them and that's it. > >> You can link > >> against NSS, but then you also get libdl and libpthread, which we do not > >> want as dependencies of libgcrypt. > > > > i'm not sure what you're saying here. `pkg-config --libs nss` doesn't > > pull in any of those libs. > > I get this: > > -lssl3 -lsmime3 -lnss3 -lnssutil3 -lplds4 -lplc4 -lnspr4 -lpthread -ldl depending on how nss is built, it might be a bug in your distro's .pc file. if nss is providing shared libs, then nspr/pthread/dl should be listed in Libs.private instead of Libs. that said ... > And if freebl needs nspr headers, it may pull in libnspr as well, which > depends on libpthread. but that issue exists regardless of where we source the data right ? if we ask nss-config/nspr-config (or nss.pc/nspr.pc) and it ends up linking against pthread/dl even at runtime, we've lost. -mike
Hello Florian. On Sat, 11/06/2016 at 15.44 +0200, Florian Weimer wrote: > On 06/11/2016 01:55 PM, Guido Trentalancia wrote: > > Such approach suffers the same problem as the {nss,nspr}-config > > scripts: you need to use pkg-config data from both NSS *and* NSPR > > in > > order to get all the needed header files' paths. > > This shouldn't be a problem because pkg-config knows about > dependencies > and will reflect their requirements in the generated command > lines. If > it does not, it's a bug in the distribution-provided .pc files. No, the .pc files that are usually provided by distributions for NSS only indicate /usr/include/nss3 and don't indicate that /usr/include/nspr for NSPR is also needed. That's why I posted the patch (which, for some reason, hasn't been applied yet). I suppose NSS/NSPR have not been originally designed to work as standalone libraries, and the adaptation provided by most distributions (as {nss,nspr}-config scripts and .pc files) is "buggy" in the sense that you mean. NSS header files include NSPR header files by using a relative and not an absolute path, so the NSPR header files' path MUST be supplied by also calling nspr-config and/or by also sourcing the nspr.pc file ! > The larger problem is that we do not particularly care about nss, we > want freebl, and at least Fedora doesn't provide a separate .pc file > for > that. I suppose I could have that fixed for Fedora, but I don't > know > how painful the process is for other distributions. There is no need for a separate .pc file for freebl. The problem is common to other sub-packages that are usually created by distributions: they include NSPR files by using a relative path while at the same time their .pc file only provides the path to NSS header files. The patch that I provided fixes such problem and I recommend you to commit it ! Regards, Guido
On 06/11/2016 06:18 PM, Guido Trentalancia wrote: > No, the .pc files that are usually provided by distributions for NSS > only indicate /usr/include/nss3 and don't indicate that > /usr/include/nspr for NSPR is also needed. > > That's why I posted the patch (which, for some reason, hasn't been > applied yet). But that's a clear distribution bug, which should be fixed on the distribution side. Thanks, Florian
On 05/31/2016 09:25 PM, Guido Trentalancia wrote: > When configuring and building GNU libc using the Mozilla NSS library > for cryptography (--enable-nss-crypt option), also include the > NSPR header files along with the Mozilla NSS library header files. > > Finally, when running the check-local-headers test, ignore the > Mozilla NSPR library header files (used by the Mozilla NSS library) > as otherwise false positives (FAIL) are obtained. > > 2016-05-31 Guido Trentalancia<guido@trentalancia.net> > > [BZ #17956] > * configure: If the Mozilla NSS library is used for > cryptography (--enable-nss-crypt option), also include > the Mozilla NSPR header files when building the test > program. Fail if Mozilla NSPR cannot be found. > > * configure.ac: Likewise. > > * crypt/Makefile: Include the Mozilla NSPR header files > when the Mozilla NSS library is used for cryptography > (--enable-nss-crypt configure option). > > * scripts/check-local-headers.sh: Ignore the Mozilla NSPR header > files. I was finally able to verify this change and pushed it, with a minor crypt/Makefile tweak and a slightly reworded ChangeLog. Thanks, Florian
4.10.2017 15:17 Florian Weimer <fweimer@redhat.com> wrote: > > > On 05/31/2016 09:25 PM, Guido Trentalancia wrote: > > When configuring and building GNU libc using the Mozilla NSS library > > for cryptography (--enable-nss-crypt option), also include the > > NSPR header files along with the Mozilla NSS library header files. > > > [...] > I was finally able to verify this change and pushed it, with a minor > crypt/Makefile tweak and a slightly reworded ChangeLog. > > Thanks, > Florian Thank you, Guido and Florian. After the recent changes in nss-util [1] this bug made glibc FTBFS in Fedora Rawhide which I experienced today. See more info: [2] [3] [4]. Regards, Rafal [1] https://src.fedoraproject.org/rpms/nss-util/c/b3b2d60 [2] https://sourceware.org/bugzilla/show_bug.cgi?id=17956 [3] https://bugzilla.redhat.com/show_bug.cgi?id=953277 [4] https://bugzilla.redhat.com/show_bug.cgi?id=1113172#c14
--- glibc-31052016-0900GMT/configure 2016-05-30 13:25:35.299696688 +0200 +++ glibc-configure-nss-crypt-include-nspr-headers/configure 2016-05-31 13:57:28.117571376 +0200 @@ -3501,8 +3501,12 @@ if test x$nss_crypt = xyes; then if test $? -ne 0; then as_fn_error $? "cannot find include directory with nss-config" "$LINENO" 5 fi + nspr_includes=-I$(nspr-config --includedir 2>/dev/null) + if test $? -ne 0; then + as_fn_error $? "cannot find include directory with nspr-config" "$LINENO" 5 + fi old_CFLAGS="$CFLAGS" - CFLAGS="$CFLAGS $nss_includes" + CFLAGS="$CFLAGS $nss_includes $nspr_includes" cat confdefs.h - <<_ACEOF >conftest.$ac_ext /* end confdefs.h. */ --- glibc-31052016-0900GMT/configure.ac 2016-05-30 13:25:35.299696688 +0200 +++ glibc-configure-nss-crypt-include-nspr-headers/configure.ac 2016-05-31 13:58:03.962731844 +0200 @@ -311,8 +311,12 @@ if test x$nss_crypt = xyes; then if test $? -ne 0; then AC_MSG_ERROR([cannot find include directory with nss-config]) fi + nspr_includes=-I$(nspr-config --includedir 2>/dev/null) + if test $? -ne 0; then + AC_MSG_ERROR([cannot find include directory with nspr-config]) + fi old_CFLAGS="$CFLAGS" - CFLAGS="$CFLAGS $nss_includes" + CFLAGS="$CFLAGS $nss_includes $nspr_includes" AC_COMPILE_IFELSE([AC_LANG_PROGRAM([typedef int PRBool; #include <hasht.h> #include <nsslowhash.h> --- glibc-31052016-0900GMT/crypt/Makefile 2016-05-30 13:25:35.306696710 +0200 +++ glibc-configure-nss-crypt-include-nspr-headers/crypt/Makefile 2016-05-31 14:28:38.995883272 +0200 @@ -37,9 +37,9 @@ routines += $(libcrypt-routines) endif ifeq ($(nss-crypt),yes) -CPPFLAGS-sha256-crypt.c = -DUSE_NSS -I$(shell nss-config --includedir) -CPPFLAGS-sha512-crypt.c = -DUSE_NSS -I$(shell nss-config --includedir) -CPPFLAGS-md5-crypt.c = -DUSE_NSS -I$(shell nss-config --includedir) +CPPFLAGS-sha256-crypt.c = -DUSE_NSS -I$(shell nss-config --includedir) -I$(shell nspr-config --includedir) +CPPFLAGS-sha512-crypt.c = -DUSE_NSS -I$(shell nss-config --includedir) -I$(shell nspr-config --includedir) +CPPFLAGS-md5-crypt.c = -DUSE_NSS -I$(shell nss-config --includedir) -I$(shell nspr-config --includedir) LDLIBS-crypt.so = -lfreebl3 else libcrypt-routines += md5 sha256 sha512 --- glibc-orig/scripts/check-local-headers.sh 2016-05-30 20:00:01.565571016 +0200 +++ glibc/scripts/check-local-headers.sh 2016-05-30 20:00:22.049496606 +0200 @@ -33,7 +33,7 @@ exec ${AWK} -v includedir="$includedir" BEGIN { status = 0 exclude = "^" includedir \ - "/(.*-.*-.*/|.*-.*/|)(asm[-/]|arch|linux/|selinux/|mach/|device/|hurd/(((hurd|ioctl)_types|paths)\\.h|ioctls\\.defs|ihash\\.h)|cthreads\\.h|gd|nss3/|c\\+\\+/|sys/(capability|sdt(|-config))\\.h|libaudit\\.h)" + "/(.*-.*-.*/|.*-.*/|)(asm[-/]|arch|linux/|selinux/|mach/|device/|hurd/(((hurd|ioctl)_types|paths)\\.h|ioctls\\.defs|ihash\\.h)|cthreads\\.h|gd|nss3/|nspr/|c\\+\\+/|sys/(capability|sdt(|-config))\\.h|libaudit\\.h)" } /^[^ ]/ && $1 ~ /.*:/ { obj = $1 } {
When configuring and building GNU libc using the Mozilla NSS library for cryptography (--enable-nss-crypt option), also include the NSPR header files along with the Mozilla NSS library header files. Finally, when running the check-local-headers test, ignore the Mozilla NSPR library header files (used by the Mozilla NSS library) as otherwise false positives (FAIL) are obtained. 2016-05-31 Guido Trentalancia <guido@trentalancia.net> [BZ #17956] * configure: If the Mozilla NSS library is used for cryptography (--enable-nss-crypt option), also include the Mozilla NSPR header files when building the test program. Fail if Mozilla NSPR cannot be found. * configure.ac: Likewise. * crypt/Makefile: Include the Mozilla NSPR header files when the Mozilla NSS library is used for cryptography (--enable-nss-crypt configure option). * scripts/check-local-headers.sh: Ignore the Mozilla NSPR header files. Signed-off-by: Guido Trentalancia <guido@trentalancia.net> --- configure | 6 +++++- configure.ac | 6 +++++- crypt/Makefile | 6 +++--- scripts/check-local-headers.sh | 2 +- 4 files changed, 14 insertions(+), 6 deletions(-)