[Bug build/23807] failure in scripts/test-installation.pl: libnss_db.so: undefined reference to `__open_nocancel@GLIBC_PRIVATE'

["adhemerval.zanella at linaro dot org" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=23807

--- Comment #3 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
(In reply to dilyan.palauzov@aegee.org from comment #2)
> I had already the first snippet including nss_nis and nss_nisplus due to
> https://sourceware.org/bugzilla/show_bug.cgi?id=21911#c3 .

Thanks, I was not aware to this issue.

> 
> I have used the installation procedure at
> https://www.tldp.org/HOWTO/html_single/Glibc-Install-HOWTO/#after-the-kernel-
> is-booted .  It has worked for more than ten years.  Well, I have not booted
> the system in single-user mode, but I do not think this is relavant here. 
> In particular, the manual doesn’t say anything about DESTDIR and chroot.

This is not the canonical to documentation unfortunately. We have a FAQ
regarding installation [1] as it notes on 'How do I install all of the GNU C
Library project libraries that I just built?':

"The only pedantically correct way to install these libraries is to install
them first into a temporary directory such as /tmp/glibc via make install
DESTDIR=/tmp/glibc, then copy that directory into an initial root disk, boot
the initial root disk, and copy the results to your root filesystem, and then
pivot into the root filesystem as the final step of booting. That is the *only*
safe way to install glibc today."

> 
> In any case, I could install some months ago libc-2.28 on a different system
> using the same procedure and the first snippet was sufficient.  However I
> used then older gcc and binutils, that is why I asked how can I verify if
> the troubles come from them.  Of course there are for sure other differences
> between both systems, not only binutils and gcc versions.
> 
> The second snippet does not help.
> 
> Moreover, after leaving glibc half-installed, by adding nss_db to the
> exclusive list in scripts/test-install.pl, and calling again make install,
> which completes and doing in gcc-7-branch
> 
> 	../configure --enable-threads=posix --enable-nls --disable-multilib
> --enable-interpreter --with-system-zlib --enable-libgcj-multifile
> --enable-languages=all --enable-targets=all --with-system-unwind --without-x
> --with-linker-hash-style=gnu --enable-shared
> --with-build-config=bootstrap-lto\ bootstrap-O3 
> 
> I get in config.log:
> 
> configure:5724: checking for the correct version of the gmp/mpfr/mpc
> libraries
> configure:5755: gcc -o conftest -g -O2    conftest.c  -lmpc -lmpfr -lgmp >&5
> /usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../../x86_64-pc-linux-gnu/
> bin/ld: /lib64/libm.so.6: undefined reference to `__strtod_nan@GLIBC_PRIVATE'
> /usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../../x86_64-pc-linux-gnu/
> bin/ld: /lib64/libm.so.6: undefined reference to
> `__strtof128_nan@GLIBC_PRIVATE'
> /usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../../x86_64-pc-linux-gnu/
> bin/ld: /lib64/libm.so.6: undefined reference to `__strtof_nan@GLIBC_PRIVATE'
> /usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../../x86_64-pc-linux-gnu/
> bin/ld: /lib64/libm.so.6: undefined reference to
> `__strtold_nan@GLIBC_PRIVATE'
> collect2: error: ld returned 1 exit status
> configure:5755: $? = 1
> configure: failed program was:
> | /* confdefs.h */
> | #define PACKAGE_NAME ""
> | #define PACKAGE_TARNAME ""
> | #define PACKAGE_VERSION ""
> | #define PACKAGE_STRING ""
> | #define PACKAGE_BUGREPORT ""
> | #define PACKAGE_URL ""
> | #define LT_OBJDIR ".libs/"
> | /* end confdefs.h.  */
> | #include <mpc.h>
> | int
> | main ()
> | {
> 
> where /lib64/libm.so.6 is the just installed one.
> 
> That said I suspect that the symbols @GLIBC_PRIVATE are not included.

I still think your installation is broken in some point. GLIBC_PRIVATE symbols
are, as the name indicates, private to glibc libraries and can change over
releases. It also means glibc does not support mixing libraries with different
version (for instance 2.27 libm with 2.28 libc).

The __strto[f,d]_nan, for instance, on 2.28 should be provided by libc.so:

$ objdump -T libc.so | grep __strto[d,f]_nan
0000000000044a50 g    DF .text  00000000000000d7  GLIBC_PRIVATE __strtod_nan
00000000000449a0 g    DF .text  00000000000000a2  GLIBC_PRIVATE __strtof_nan

I can't tell why it was working before and not now, but the issue seems to be
with your installation.

[1] https://sourceware.org/glibc/wiki/FAQ#Installation_and_configuration_issues

-- 
You are receiving this mail because:
You are on the CC list for the bug.