You are not logged in.
I had been seeing the following message recently:
ldconfig: /usr/lib/libbfd.so is not an ELF file - it has the wrong magic bytes at the startso I checked out /usr/lib/libbfd.so and it turns out it's a text file, containing the following:
[root@bslxhp32 lib]# cat libbfd.so
INPUT( /usr/lib/libbfd.a -lsframe -liberty -lz -lzstd -ldl )I double-checked this file against the 64-bit version, and archlinux's libbfd.so is exactly the same, so the package build is right (which I confirmed with my own rebuild), but I don't see the linker warning on my 64-bit archlinux system (I'm assuming it's a warning since so far it hasn;t seemed to crash anything). Any thoughts as to why the difference between the 2 systems, and is there any way to silence the warnings (the 2 questions may have the same answer)?
Last edited by jghodd (2023-02-01 22:00:56)
Offline
Yeah, noticed that to. libbfd.so is a linker script file on 32-bit and upstream on 64-bit. Calling ldconfig on 64-bit doesn't show this warning, 32-bit does.
Both versions of ldconfig from glibc are 2.36 (package 2.36-7). glibc 2.37 is in testing, so let's wait and see if the error persists.
This is something ldconfig should know and not treat linker scripts like ELF libraries.. :-)
Offline
On my 32-bit system, I've not yet updated this year because I've nun out of space in my /usr partiton, and have glibc2.36-6.0. That doesn't report errors either.
Architecture: pentium4, Testing repos: Yes, Hardware: EeePC 901+2GB RAM+OS half on the SD card.
Offline
glibc/src/glibc/elf/ldconfig.c:
elf_header = (ElfW(Ehdr) *) file_contents;
if (memcmp (elf_header->e_ident, ELFMAG, SELFMAG) != 0)
{
/* The file is neither ELF nor aout. Check if it's a linker
script, like libc.so - otherwise complain. Only search the
beginning of the file. */
size_t len = MIN (statbuf.st_size, 512);
if (memmem (file_contents, len, "GROUP", 5) == NULL
&& memmem (file_contents, len, "GNU ld script", 13) == NULL
&& !is_gdb_python_file (file_name))
error (0, 0, _("%s is not an ELF file - it has the wrong magic bytes at the start.\n"),
file_name);
ret = 1;
}
So, libbfd is just a little bit older and the signature "GNU ld script" is missing in the beginning.
So, we have to rebuild libbfd for the error to go away.
Still, this is not a real problem but rather a cosmetic bug..
There is also the possibility that 32-bit and 64-bit have different linker scripts and nobody bothers
to adapt the 32-bit version.. :-)
Offline
# No shared linking to these files outside binutils
rm -f "$pkgdir"/usr/lib/lib{bfd,opcodes}.so
echo 'INPUT( /usr/lib/libbfd.a -lsframe -liberty -lz -lzstd -ldl )' > "$pkgdir/usr/lib/libbfd.so"
echo 'INPUT( /usr/lib/libopcodes.a -lbfd )' > "$pkgdir/usr/lib/libopcodes.so"
So the bug is in the upstream PKGBUILD, why we have a newer version than upstream
is unclear to me though..
I'll open a bug upsteam..
Offline
Reported upsteam: https://bugs.archlinux.org/task/77365
Offline
Has this been reviewed? I'm still gettind the "is not an ELF file" error
Offline
Yes:
-rw-r--r-- 1 http http 10122649 Feb 8 01:42 glibc-2.37-2.1-i486.pkg.tar.zst
-rw-r--r-- 1 http http 10146245 Feb 8 10:50 glibc-2.37-2.1-i686.pkg.tar.zst
-rw-r--r-- 1 http http 10148746 Feb 8 08:29 glibc-2.37-2.1-pentium4.pkg.tar.zst
lrwxrwxrwx 1 http http 50 Feb 3 22:43 ../pentium4/core/glibc-2.36-7.1-pentium4.pkg.tar.zst.sig -> ../../pool/glibc-2.36-7.1-pentium4.pkg.tar.zst.sig
lrwxrwxrwx 1 http http 46 Feb 7 12:21 ../pentium4/testing/glibc-2.37-2.0-pentium4.pkg.tar.zst -> ../../pool/glibc-2.37-2.0-pentium4.pkg.tar.zst
But, the buildmaster holds the pushing to stable back (it would be an update from glibc 2.36 to 2.37).
The dangers of doing so forcefully are too high compared to a harmless warning in ldconfig.
That said, glibc 2.37 should get to stable for other reasons.. :-)
Offline