Wnen I try to build curl the configure process fail with : /bin/sh: error while loading shared libraries: /usr/lib/libncurses.so.5: invalid ELF header Reproducible: Always Steps to Reproduce: 1. emerge -v curl 2. 3. Actual Results: checking whether to enable SSPI support (Windows native builds only)... no checking whether to enable cryptographic authentication methods... yes checking whether to enable TLS-SRP authentication... yes checking whether to enable support for cookies... yes checking whether to enable hidden symbols in the library... no checking whether to enforce SONAME bump... no configure: creating ./config.status /bin/sh: error while loading shared libraries: /usr/lib/libncurses.so.5: invalid ELF header The problem is somewhere in option used to configure curl because if I try to configure curl with default options it worlk properly. I've searched for libncurses.so.5 revdep but no problem has been found.
Created attachment 285829 [details] emerge --info
Created attachment 285831 [details] build.log
So did you run revdep-rebuild yet?
Already done as write in my comment...But nothing has changed
Can you try it with ccache disabled?
(In reply to comment #4) > Already done as write in my comment...But nothing has changed You wrote: "I've searched for libncurses.so.5 revdep but no problem has been found." That is not English for "I ran revdep-rebuild." Just saying.
(In reply to comment #0) > The problem is somewhere in option used to configure curl because if I try to > configure curl with default options it worlk properly. Please define "default options" and the difference to the failing build.
(In reply to comment #7) > (In reply to comment #0) > > The problem is somewhere in option used to configure curl because if I try to > > configure curl with default options it worlk properly. > > Please define "default options" and the difference to the failing build. I mean the option that are created when I run ./configure from the source.
(In reply to comment #5) > Can you try it with ccache disabled? Yes nothing change
These are the default options from ./configure output: SSL support: enabled (OpenSSL) SSH support: enabled (libSSH2) zlib support: enabled resolver: default (--enable-ares / --enable-threaded-resolver) IDN support: enabled Build libcurl: Shared=yes, Static=yes Built-in manual: enabled Verbose errors: enabled (--disable-verbose) LDAP support: enabled (OpenLDAP) LDAPS support: enabled RTSP support: enabled Protocols: DICT FILE FTP FTPS GOPHER HTTP HTTPS IMAP IMAPS LDAP LDAPS POP3 POP3S RTSP SCP SFTP SMTP SMTPS TELNET TFTP while these are the portage options: ares ipv6 kerberos ldap nss ssl
please try the exact same configure options (you can get those from your build.log) and also please try 7.22
(In reply to comment #11) > please try the exact same configure options (you can get those from your > build.log) and also please try 7.22 Same problem with 7.22 and with the same configure options. I've found the problem and the solution...in an HARD WAY!!! Practically I've debugged the configure process to see where the problem was and the problem was the LD_LIBRARY_PATH ; I try to explain what happens. In a new shell my LD_LIBRARY_PATH is /mnt/oracle/OraHome1/lib:/mnt/oracle/OraHome1/network/lib Adding debugging to the configure script I've seen that the LD_LIBRARY_PATH was modified in: LD_LIBRARY_PATH=/mnt/oracle/OraHome1/lib:/mnt/oracle/OraHome1/network/lib:/usr/lib This generate the original error: /bin/sh: error while loading shared libraries: /usr/lib/libncurses.so.5: invalid ELF header At this point if I set this LD_LIBRARY_PATH to a new shell I get the same error for everything linked to ncurses. BUT the error occurs only then file /usr/lib/libncurses.so.5 is the GNU ld script: /* GNU ld script Since Gentoo has critical dynamic libraries in /lib, and the static versions in /usr/lib, we need to have a "fake" dynamic lib in /usr/lib, otherwise we run into linking problems. This "fake" dynamic lib is a linker script that redirects the linker to the real lib. And yes, this works in the cross- compiling scenario as the sysroot-ed linker will prepend the real path. See bug http://bugs.gentoo.org/4411 for more info. */ OUTPUT_FORMAT ( elf64-x86-64 ) GROUP ( /lib64/libncurses.so.5.7 ) If I substitute the ld script file with a direct link to /lib64/libncurses.so.5.7 the problem not happens. At the moment I'vnt find the way to build the package without error; every time the LD_LIBRARY_PATH is set although the var was initially not set. So I think the problem is somewhere in the curl configuration process. Perhaps could be useful to assign the problem to the curl maintainer to clarify why it modifies the LD_LIBRARY_PATH and to linker team to understand because its fail to recognize the correct library.
I add some info. If I run the configure without option the process run without error basically for 2 reason: 1) the /bin/sh ./config.status isn't called + echo '/bin/sh -x ./config.status || ac_cs_success=false' + exec + : + test '' '!=' yes + ac_sub_configure_args= 2) in every case the LD_LIBRARY_PATH is not modified
I've found a WORKAROUND but it isn't THE SOLUTION! If I set the LD_LIBRARY_PATH=/lib64 all works because after the configure however the linker search before in /lib64 where is contained the real lib.
Founded and resolved one problem. In /usr/local I had: -rwxr-xr-x 1 root root 527 Sep 27 16:03 libncurses.so lrwxrwxrwx 1 root root 22 Sep 27 14:40 libncurses.so.5 -> /usr/lib/libncurses.so With the LD_LIBRARY_PATH=/usr/lib variable exported every command fails because it parse the link libncurses.so.5 and crash: writev(2, [{"vi", 2}, {": ", 2}, {"error while loading shared libra"..., 36}, {": ", 2}, {"/usr/lib /libncurses.so.5", 24}, {": ", 2}, {"invalid ELF header", 18}, {"", 0}, {"", 0}, {"\n", 1}], 10vi: error while loading shared libraries: /usr/lib/libncurses.so.5: invalid ELF header ) = 87 exit_group(127) = ? I don't know why that link doesn't like to the linker! When I remove the link /usr/lib/libncurses.so.5 everything work properly(thanks Alberto).
what does `ls -ld /usr/lib* /lib*` show ?
in the mean time, i've tweaked the 7.23.1 ebuild: sed -i '/LD_LIBRARY_PATH=/d' configure.ac || die #382241
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f7d7fb78e3689b5a56f384d9e0eca42ac36b23c7 commit f7d7fb78e3689b5a56f384d9e0eca42ac36b23c7 Author: Sam James <sam@gentoo.org> AuthorDate: 2021-07-22 02:52:33 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-07-22 03:20:27 +0000 net-misc/curl: add 7.78.0 * Security bump to 7.78.0 * Drops metalink support (gone upstream entirely) * Drops two obsolete seds Bug: https://bugs.gentoo.org/382241 Bug: https://bugs.gentoo.org/637252 Bug: https://bugs.gentoo.org/803308 Signed-off-by: Sam James <sam@gentoo.org> net-misc/curl/Manifest | 1 + net-misc/curl/curl-7.78.0.ebuild | 289 +++++++++++++++++++++++++++++++++++++++ 2 files changed, 290 insertions(+)
