You are not logged in.

#1 2019-07-14 14:41:37

jghodd
Member
Registered: 2019-07-14
Posts: 18

[SOLVED] linker error (glibc bug)

I'm seeing an issue with glibc after the last major software update. There's a persistent warning about an ld-linux.so.2 error that is causing an error with my ld preloads and at least one of my software builds:

[  1%] Linking CXX executable txload
/bin/ld: warning: /usr/lib/ld-linux.so.2: corrupt GNU_PROPERTY_TYPE (5) size: 0
/bin/ld: warning: /usr/lib/ld-linux.so.2: corrupt GNU_PROPERTY_TYPE (5) size: 0
collect2: error: ld returned 1 exit status
make[2]: *** [lang/CMakeFiles/txload.dir/build.make:86: lang/txload] Error 1
make[1]: *** [CMakeFiles/Makefile2:251: lang/CMakeFiles/txload.dir/all] Error 2
make: *** [Makefile:141: all] Error 2
==> ERROR: A failure occurred in build().
    Aborting...


And the LD_PRELOAD error:

ERROR: ld.so: object '/usr/${LIB}/libgtk3-nocsd.so.0' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.

I've checked ld-linux and it is properly symlinked to ld-2.29.so. I've also tried the 2.29-3 version of glibc currently in staging, as well as rebuilding glibc with --enable-cet as advised in the arch64 bugtracker - https://bugs.archlinux.org/task/63015. Nothing fixes the issue so far.

I also opened a new bug report at https://bugs.archlinux32.org/index.php? … task_id=82 on July 11 and have yet to receive any response.

I'd consider this to be a pretty significant bug that probably needs some kind of resolution pretty quickly.

I'm not seeing this issue on my arch64 system.

Last edited by jghodd (2019-07-22 18:15:43)

Offline

#2 2019-07-16 03:39:03

jghodd
Member
Registered: 2019-07-14
Posts: 18

Re: [SOLVED] linker error (glibc bug)

Okay...

First, the PRELOAD issue turned out to be a non-issue. $LIB was resolving to null. So, something changed somewhere, but hard-coding $LIB to "lib" fixed the problem.

As for the glibc issue, I;ve narrowed down the offending upgrade to glibc-2.29-1.26 -> glibc-2.29-1.27. There were 3 changes made to the glibc PKGBUILD for the glibc-2.29-1.27 release. One of them caused this issue. Also, I'm not the only person out there to be experiencing build failures due to this linker warning. Apparently the warning causes ld to return a 1 exit status which can cause a build to fail (apparently not always, so I'm guessing it depends on the compile/link options).

If Erich Eckner reads these forum entries, I'm looking at you, bud. Please fix this.

Offline

#3 2019-07-16 05:33:15

andreas_baumann
Administrator
From: Zurich, Switzerland
Registered: 2017-08-10
Posts: 755
Website

Re: [SOLVED] linker error (glibc bug)

There is another thing which can change: the toolchain.
This GNU_PROPERTY error is something the compiler emits (we think it's CET stuff, but it's badly
documented). Binutils ld seems not to like this ELF section.

The error is the same as in:

https://bugs.archlinux.org/task/63015

What's puzzling me: --enable-cet is there in glibc, gcc, binutils (just not for i486, as CET doesn't\
work for older CPUs).

Commit: 09d03cbd4c57b8eabfadd22b67929d958b2409d7 and d57a456faa674c24e8869a26a14c497c95accf1f in
glibc are mine, they try to change stack alignment and handling of SSE for pentium4 for Java, also without effect.

Offline

#4 2019-07-16 05:35:32

andreas_baumann
Administrator
From: Zurich, Switzerland
Registered: 2017-08-10
Posts: 755
Website

Re: [SOLVED] linker error (glibc bug)

About linker warnings being turned to errors (as for compiler warnings turned to errors): this
is something the DEVELOPER should do, NOT the PACKAGER. Released software should:
- NOT include asserts
- NOT include debug code
- NOT include code only used for running tests
- NOT use -Werror
- NOT use -Wl,--fatal-warnings

See for instance extra-cmake-modules-5.59.0-ld-no-fatal-warning.patch.

Offline

#5 2019-07-16 20:45:42

deep42thought
Administrator
From: Jena, Germany
Registered: 2017-06-17
Posts: 433

Re: [SOLVED] linker error (glibc bug)

I can confirm that simply downgrading glibc to the 2.29-1.26 version on i686 gets rid of the warning, whereas 2.29-1.27 exhibits the warning.

There were several changes of installed packages during the build - here is a diff of the .BUILDINFO:

@@ -1,4 +1,4 @@
-builddate = 1556106488
+builddate = 1559897932
 builddir = /build
 buildenv = !ccache
 buildenv = !distcc
@@ -9,155 +9,155 @@
 installed = acl-2.2.53-1.3-i686
 installed = archlinux-keyring-20190123-2.0-any
 installed = archlinux32-keyring-20190108-1.0-any
-installed = argon2-20171227-3.3-i686
-installed = attr-2.4.48-1.3-i686
-installed = audit-2.8.4-3.3-i686
+installed = argon2-20171227-3.4-i686
+installed = attr-2.4.48-1.4-i686
+installed = audit-2.8.5-2.0-i686
 installed = autoconf-2.69-5.1-any
 installed = automake-1.16.1-1.1-any
-installed = bash-5.0.003-1.1-i686
-installed = binutils-2.31.1-4.0-i686
+installed = bash-5.0.007-1.0-i686
+installed = binutils-2.32-1.10-i686
 installed = bison-3.3.2-1.0-i686
-installed = bzip2-1.0.6-8.6-i686
+installed = bzip2-1.0.6-8.7-i686
 installed = ca-certificates-20181109-1.0-any
-installed = ca-certificates-mozilla-3.43-1.0-i686
+installed = ca-certificates-mozilla-3.44-1.0-i686
 installed = ca-certificates-utils-20181109-1.0-any
-installed = coreutils-8.31-1.0-i686
-installed = cracklib-2.9.6-3.0-i686
+installed = coreutils-8.31-1.2-i686
+installed = cracklib-2.9.7-1.0-i686
 installed = cryptsetup-2.1.0-1.0-i686
-installed = curl-7.64.1-2.0-i686
+installed = curl-7.65.0-2.0-i686
 installed = db-5.3.28-4.4-i686
-installed = dbus-1.12.12-1.0-i686
-installed = device-mapper-2.02.184-4.0-i686
+installed = dbus-1.12.14-1.0-i686
+installed = device-mapper-2.02.184-4.2-i686
 installed = diffutils-3.7-1.0-i686
-installed = e2fsprogs-1.45.0-1.0-i686
-installed = expat-2.2.6-1.2-i686
+installed = e2fsprogs-1.45.2-1.0-i686
+installed = expat-2.2.6-1.3-i686
 installed = fakeroot-1.23-1.5-i686
-installed = file-5.36-1.0-i686
-installed = filesystem-2018.12-2.2-i686
-installed = findutils-4.6.0-4.0-i686
+installed = file-5.37-2.0-i686
+installed = filesystem-2019.05-2.0-i686
+installed = findutils-4.6.0-4.1-i686
 installed = flex-2.6.4-2.0-i686
 installed = fontconfig-2:2.13.1+12+g5f5ec56-1.0-i686
-installed = freetype2-2.10.0-1.0-i686
+installed = freetype2-2.10.0-2.0-i686
 installed = gawk-4.2.1-2.3-i686
 installed = gc-7.6.8-1.1-i686
-installed = gcc-8.2.1+20181127-1.2-i686
-installed = gcc-libs-8.2.1+20181127-1.2-i686
-installed = gd-2.2.5-1.1-i686
+installed = gcc-8.3.0-1.0-i686
+installed = gcc-libs-8.3.0-1.0-i686
+installed = gd-2.2.5-2.0-i686
 installed = gdbm-1.18.1-2.3-i686
 installed = gettext-0.19.8.1-3.0-i686
 installed = giflib-5.1.9-3.0-i686
-installed = git-2.21.0-1.0-i686
-installed = glib2-2.60.0-1.0-i686
-installed = glibc-2.29-1.25-i686
+installed = git-2.21.0-1.1-i686
+installed = glib2-2.60.3-1.0-i686
+installed = glibc-2.29-1.26-i686
 installed = gmp-6.1.2-2.0-i686
-installed = gnupg-2.2.15-1.0-i686
-installed = gnutls-3.6.7-1.0-i686
+installed = gnupg-2.2.16-1.0-i686
+installed = gnutls-3.6.8-1.0-i686
 installed = gpgme-1.13.0-1.0-i686
-installed = graphite-1:1.3.13-1.0-i686
+installed = graphite-1:1.3.13-1.1-i686
 installed = grep-3.3-1.0-i686
-installed = groff-1.22.3-8.1-i686
+installed = groff-1.22.4-1.1-i686
 installed = guile-2.2.4-2.1-i686
 installed = gzip-1.10-1.0-i686
-installed = harfbuzz-2.4.0-2.0-i686
-installed = hwids-20180917-1.0-any
-installed = iana-etc-20190329-1.0-any
-installed = icu-64.1-1.0-i686
-installed = iptables-1:1.8.2-1.0-i686
-installed = json-c-0.13.1-2.4-i686
-installed = kbd-2.0.4-2.0-i686
+installed = harfbuzz-2.5.1-1.0-i686
+installed = hwids-20190316-1.0-any
+installed = iana-etc-20190531-1.0-any
+installed = icu-64.2-1.0-i686
+installed = iptables-1:1.8.2-1.2-i686
+installed = json-c-0.13.1-2.5-i686
+installed = kbd-2.0.4-2.2-i686
 installed = keyutils-1.6-1.0-i686
 installed = kmod-26-2.0-i686
-installed = krb5-1.16.1-1.3-i686
-installed = less-530-1.5-i686
+installed = krb5-1.16.2-1.0-i686
+installed = less-530-1.6-i686
 installed = libarchive-3.3.3-1.3-i686
 installed = libassuan-2.5.3-1.1-i686
 installed = libatomic_ops-7.6.10-1.0-i686
-installed = libcap-2.26-1.0-i686
-installed = libcap-ng-0.7.9-1.3-i686
+installed = libcap-2.27-1.0-i686
+installed = libcap-ng-0.7.9-1.4-i686
 installed = libcroco-0.6.13-1.0-i686
 installed = libelf-0.176-1.0-i686
 installed = libffi-3.2.1-3.0-i686
 installed = libgcrypt-1.8.4-1.1-i686
 installed = libgpg-error-1.36-1.0-i686
 installed = libice-1.0.9-2.1-i686
-installed = libidn2-2.1.1-2.3-i686
-installed = libjpeg-turbo-2.0.2-1.0-i686
-installed = libksba-1.3.5-1.2-i686
+installed = libidn2-2.1.1-2.5-i686
+installed = libjpeg-turbo-2.0.2-1.1-i686
+installed = libksba-1.3.5-1.3-i686
 installed = libldap-2.4.47-1.0-i686
 installed = libmnl-1.0.4-2.0-i686
 installed = libmpc-1.1.0-1.2-i686
 installed = libnetfilter_conntrack-1.0.7-1.3-i686
-installed = libnfnetlink-1.0.1-3.1-i686
+installed = libnfnetlink-1.0.1-3.2-i686
 installed = libnftnl-1.1.1-1.3-i686
 installed = libnghttp2-1.36.0-1.0-i686
-installed = libnl-3.4.0-1.3-i686
-installed = libnsl-1.2.0-1.3-i686
-installed = libpcap-1.9.0-1.3-i686
-installed = libpng-1.6.36-1.0-i686
+installed = libnl-3.4.0-1.4-i686
+installed = libnsl-1.2.0-1.5-i686
+installed = libpcap-1.9.0-1.4-i686
+installed = libpng-1.6.37-1.0-i686
 installed = libpsl-0.20.2-5.1-i686
 installed = libsasl-2.1.27-1.2-i686
-installed = libseccomp-2.4.0-1.1-i686
-installed = libsecret-0.18.8-2.0-i686
+installed = libseccomp-2.4.1-2.0-i686
+installed = libsecret-0.18.8-2.1-i686
 installed = libsm-1.2.3-1.0-i686
-installed = libssh2-1.8.1-1.0-i686
-installed = libtasn1-4.13-1.3-i686
+installed = libssh2-1.8.2-1.0-i686
+installed = libtasn1-4.13-1.4-i686
 installed = libtiff-4.0.10-1.0-i686
 installed = libtirpc-1.1.4-1.0-i686
-installed = libtool-2.4.6+42+gb88cebd5-2.1-i686
-installed = libunistring-0.9.10-1.10-i686
-installed = libusb-1.0.22-1.5-i686
-installed = libutil-linux-2.33.2-1.0-i686
+installed = libtool-2.4.6+42+gb88cebd5-3.0-i686
+installed = libunistring-0.9.10-1.11-i686
+installed = libusb-1.0.22-1.6-i686
+installed = libutil-linux-2.33.2-1.2-i686
 installed = libwebp-1.0.2-1.0-i686
 installed = libx11-1.6.7-1.0-i686
 installed = libxau-1.0.9-1.0-i686
 installed = libxcb-1.13.1-1.0-i686
 installed = libxdmcp-1.1.3-1.0-i686
 installed = libxext-1.3.4-1.0-i686
-installed = libxml2-2.9.9-2.0-i686
+installed = libxml2-2.9.9-2.3-i686
 installed = libxpm-3.5.12-2.0-i686
 installed = libxt-1.1.5-2.2-i686
 installed = linux-api-headers-5.0.7-1.0-any
-installed = lz4-1:1.8.3-1.1-i686
+installed = lz4-1:1.9.1-1.0-i686
 installed = m4-1.4.18-2.0-i686
 installed = make-4.2.1-3.0-i686
 installed = mpfr-4.0.2-1.0-i686
 installed = ncurses-6.1-6.0-i686
 installed = nettle-3.4.1-1.0-i686
 installed = npth-1.6-1.3-i686
-installed = openssl-1.1.1.b-1.0-i686
-installed = p11-kit-0.23.15-1.0-i686
-installed = pacman-5.1.3-1.1-i686
+installed = openssl-1.1.1.c-1.0-i686
+installed = p11-kit-0.23.16.1-1.0-i686
+installed = pacman-5.1.3-1.6-i686
 installed = pacman-mirrorlist-20190214-1.1-any
-installed = pam-1.3.1-1.3-i686
+installed = pam-1.3.1-1.6-i686
 installed = pambase-20190105.1-1.0-any
 installed = patch-2.7.6-7.0-i686
 installed = pcre-8.43-1.0-i686
-installed = pcre2-10.32-2.1-i686
-installed = perl-5.28.1-1.0-i686
+installed = pcre2-10.33-1.0-i686
+installed = perl-5.28.2-1.0-i686
 installed = perl-error-0.17027-1.0-any
-installed = perl-mailtools-2.20-2.1-any
+installed = perl-mailtools-2.21-1.0-any
 installed = perl-timedate-2.30-5.2-any
-installed = pinentry-1.1.0-4.15-i686
+installed = pinentry-1.1.0-4.18-i686
 installed = pkgconf-1.6.1-1.0-i686
 installed = popt-1.16-10.0-i686
-installed = python-3.7.3-1.0-i686
+installed = python-3.7.3-1.1-i686
 installed = readline-8.0.0-1.1-i686
-installed = sed-4.7-1.0-i686
-installed = shadow-4.6-2.1-i686
-installed = sqlite-3.27.2-1.0-i686
-installed = sudo-1.8.27-1.0-i686
-installed = systemd-241.93-1.0-i686
-installed = systemd-libs-241.93-1.0-i686
-installed = tar-1.32-1.0-i686
+installed = sed-4.7-1.2-i686
+installed = shadow-4.6-3.0-i686
+installed = sqlite-3.28.0-1.0-i686
+installed = sudo-1.8.27-1.3-i686
+installed = systemd-242.29-1.0-i686
+installed = systemd-libs-242.29-1.0-i686
+installed = tar-1.32-1.2-i686
 installed = texinfo-6.6-1.0-i686
 installed = tzdata-2019a-1.0-i686
-installed = util-linux-2.33.2-1.0-i686
+installed = util-linux-2.33.2-1.2-i686
 installed = which-2.21-3.0-i686
 installed = xcb-proto-1.13-2.1-any
 installed = xorgproto-2018.4-1.0-any
 installed = xz-5.2.4-1.3-i686
-installed = zlib-1:1.2.11-3.2-i686
-installed = zstd-1.3.8-1.0-i686
+installed = zlib-1:1.2.11-3.3-i686
+installed = zstd-1.4.0-1.0-i686
 options = !debug
 options = !libtool
 options = !staticlibs
@@ -166,9 +166,9 @@
 options = purge
 options = strip
 options = zipman
-packager = Erich Eckner <arch32 at eckner dot net>
+packager = Andreas Baumann <mail@andreasbaumann.cc>
 pkgarch = i686
 pkgbase = glibc
-pkgbuild_sha256sum = b574772e7be67dd619ef1cc26ffbd3b3cf0cddd50816ae7ea56396e0f2b8d812
+pkgbuild_sha256sum = 00f0fac208124a6056c089e5780164b68a5c89cebc7374ef8c050b9483031c09
 pkgname = glibc
-pkgver = 2.29-1.26
+pkgver = 2.29-1.27

I see gcc and binutils. Might this explain something?

Offline

#6 2019-07-16 21:20:53

jghodd
Member
Registered: 2019-07-14
Posts: 18

Re: [SOLVED] linker error (glibc bug)

- andreas_baumann

I knew about the cet issue. did quite abit of looking around to get some insight into it (even looked at the code - elf-properties.c - and it looks like the Elf_Internal_Note description size is coming back with a value of 0. the other possibility is that (size % 4) is something other than 0 which is less likely). from what i could gather, cet is supposed to be enabled in the latest builds of glibc for i686 even though, as you pointed out, it's not well documented. i did do a 2.29-4 i686 build with cet enabled and it made no difference vis-a-vis the warning. i also checked the upstream diff between 2.29-1.26 and 2.29-1.27 and noticed the addition of --enable-static-pie and thought maybe position independent executables may explain it. did another glibc build with static pie disabled and that made no difference. am about to go back and check the diff again and see what else may have changed.

i did check the CMakeLists.txt file for my failing build and it uses -Werror and -Wl,--fatal-warnings so I will remove those. but that doesn;t actually fix the underlying issue of the warning which we shouldn;t be seeing.

it is up to the developer, but too often one has to show that a change fixes an issue before you'll get any attention. i may not be THE developer for this particular package, but i am A developer, so i don;t feel uncomfortable making code changes.

thanks for getting back to me, andreas. i did notice that you were also performing some of the commits into glibc.


- deep42thought

i wondered the same thing about gcc and binutils. i went through a process of elimination with the gcc packages and can say without any doubt that gcc isn;t the problem. i did start a binutils build (thought maybe the issue might've been ld), but when i noticed that the build was failing the test suites (as well as churning out 1000s of the GNU_PROPERTY warnings), i stopped it. i may start it up again now that i'm downgraded to glibc 2.29-1.26.

i'll let y'all know if i make any headway in finding the source of the warnings. thanks much for the feedback.

Last edited by jghodd (2019-07-16 21:23:08)

Offline

#7 2019-07-17 05:12:31

andreas_baumann
Administrator
From: Zurich, Switzerland
Registered: 2017-08-10
Posts: 755
Website

Re: [SOLVED] linker error (glibc bug)

@jghodd: good analysis and explanation. :-)

We should bring this up upstream, the question is just, is it a binutils/IA32 problem, or a gcc problem?
Having a linker croak in one package when I disable/enable something in another package feels a little
bit bad, as if gcc and binutils people would not talk to each other.. :-)

Another thing we can do: is CET in a simple C test.c program (endbr32 opcode), when we compile it on
Archlinux32?

Offline

#8 2019-07-17 20:21:08

jghodd
Member
Registered: 2019-07-14
Posts: 18

Re: [SOLVED] linker error (glibc bug)

@andreas_baumann

I double-checked the arch32 commits for glibc and other than the addition of the 'file-truncated' patch, every other change was innocuous and soley aimed at making corrections for i486 and pentium4 platforms. So, I went ahead and did a glibc build without the file-truncated patch and, unfortunately, saw the same warnings. Also checked the upstream packaging changes and am not seeing anything dodgy. Of course, that doesn;t mean something wasn't added to or changed in the code base sometime between the date of the commit used to build glibc-2.29-1.26 and glibc-2.29-1.27, but I don;t have those dates or the specific commit references. Even though I show glibc-2.29-1.26 was built Apr 24, I don;t know when the code-base used for that build was committed. Ditto for glibc-2.29-1.27 which was built Jun 7. If I knew those respective dates, I might be able to narrow down what exactly changed during the interim.

I went ahead and also built the latest binutils and there was no change vis-a-vis the warning. The build did proceed and complete without error this time using the downgraded glibc.

Offline

#9 2019-07-18 06:01:58

deep42thought
Administrator
From: Jena, Germany
Registered: 2017-06-17
Posts: 433

Re: [SOLVED] linker error (glibc bug)

regarding commit dates: There is only a slight chance, that a build of version $x happens _after_ version $y>$x has been committed to git: Only when it was recorded in git, but the build-master did not update the mysql database yet (which happens every hour, but might be postponed due to missing locks).

Offline

#10 2019-07-18 15:10:09

jghodd
Member
Registered: 2019-07-14
Posts: 18

Re: [SOLVED] linker error (glibc bug)

@deep42thought

On the arch32 side of things, the timelines appear to be quite obvious and other than the introduction of the 'file-truncated' patch, I'm not seeing anything that could cause any behavioral changes in glibc. All the changes appear to be aimed at adjusting the configuration to accomodate i486 and pentium4 builds which don;t apply to i686.

However, the arch32 versioning doesn;t map directly onto the upstream versioning. i.e. 1.26 and 1.27 don;t have any obvious direct correlation to any upstream versions. That doesn;t mean that the arch32 versions don;t map directly to upstream commits, and that's what I'd like to find out. I'm guessing that'll all be a matter of timing, so knowing the dates of the 1.26 and 1.27 builds are going to be important if we're to know what was introduced to the code base between these 2 versions. It's not outside the realm of possibility that some 'fix' introduced upstream wasn;t tested on an i686 platform and may have broken 32-bit builds. In fact that seems likely since we aren;t seeing this issue on 64-bit platforms.

So, if I can get some dates, I can probably narrow down whatever changes lead to this issue.

It could also be as simple as changing the configure parameters or LDFLAGS (I did notice that "-z,now" was added to LDFLAGS in one of the commits) to accomodate some upstream change... a lot of moving parts here.

Last edited by jghodd (2019-07-18 15:18:54)

Offline

#11 2019-07-18 18:22:45

deep42thought
Administrator
From: Jena, Germany
Registered: 2017-06-17
Posts: 433

Re: [SOLVED] linker error (glibc bug)

two comments:
first, if upstream changes something, they usually change the pkgrel - thus $pkgname-$pkgver-$pkgrel.$sub_pkgrel and $pkgname-$pkgver-$pkgrel.$((sub_pkgrel+1)) should use the same upstream source. And since all the package sources are verified by checksum, those should not change either.
second, all the dates I can provide are the ones in the built packages a.k.a. "build date" - which are Wed Apr 24 11:48:08 UTC 2019 and Fri Jun  7 08:58:52 UTC 2019 for glibc-2.29-1.26 and 2.29-1.27 respectively.
Unfortunately, the packages are removed from the mysql database (which would hold the direct link between package and source commit) once they are removed from the repositories (due to a new version arriving).

My imagination is, that it's not actually related to some change in glibc or its PKGBUILD but rather to some change in the programs used to build it. Maybe we could track it by trying to build the current glibc with the same packages which were used to build 1.26 vs. the ones from 1.27? If the issue pops up there, we could bisect and find the guilty program.

Offline

#12 2019-07-18 22:32:51

jghodd
Member
Registered: 2019-07-14
Posts: 18

Re: [SOLVED] linker error (glibc bug)

@deep42thought

I concur. Your reasoning is sound. I can find the gcc and gcc-libs packages released at the time you built 1.26 and try a build using those with the most recent glibc. Let's see what happens...

Offline

#13 2019-07-19 00:15:01

jghodd
Member
Registered: 2019-07-14
Posts: 18

Re: [SOLVED] linker error (glibc bug)

so far, so good. downgraded binutils, gcc, gcc-libs, glibc, glib2 and gnutls to versions that predate the 1.26 glibc build and am currently building glibc-2.29-4 from upstream. i'd normally be seeing the GNU_PROPERTY_TYPE warning by this point in the build and so far, nothing. if this build works, i'll do it again after updating binutils and gnutls (the least likely suspects), then glib2. if all those work, then it does appear that it'd have to be gcc/gcc-libs.

Offline

#14 2019-07-19 05:08:56

deep42thought
Administrator
From: Jena, Germany
Registered: 2017-06-17
Posts: 433

Re: [SOLVED] linker error (glibc bug)

this plan sounds good. I'm keen to hear any results smile

Offline

#15 2019-07-19 15:57:31

jghodd
Member
Registered: 2019-07-14
Posts: 18

Re: [SOLVED] linker error (glibc bug)

Ok. the first build went through without a hitch. no warnings. i've updated gnutls and am doing a second build now. sorry about the slow turnaround. i have the 32-bit install on a VM and the builds take somewhere between 8 and 10 hours - painfully slow. i did notice that Erich Eckner had committed an i686 fix for cet to gcc a week ago. have to wonder if this hasn;t been the issue all along.

Last edited by jghodd (2019-07-19 16:05:32)

Offline

#16 2019-07-20 14:20:49

jghodd
Member
Registered: 2019-07-14
Posts: 18

Re: [SOLVED] linker error (glibc bug)

Doing the last downgrade build - just gcc/gcc-libs and glibc downgraded. binutils, glib2 and gnutls all at current versions. no warnings so far. next one will be with gcc/gcc-libs upgraded which i suspect will see the return of the warnings.

Last edited by jghodd (2019-07-20 14:22:05)

Offline

#17 2019-07-20 15:22:54

jghodd
Member
Registered: 2019-07-14
Posts: 18

Re: [SOLVED] linker error (glibc bug)

Ok. Seeing the warnings now with binutils upgraded to the current version. I may do another downgrade and rebuild binutils, then try again. that won't be done until tomorrow some time though.

Last edited by jghodd (2019-07-20 15:24:45)

Offline

#18 2019-07-20 19:40:48

levi
Moderator
From: Yorkshire, UK
Registered: 2018-06-16
Posts: 389

Re: [SOLVED] linker error (glibc bug)

Binutils is a suite of tools used by the build process.  Will you be able to break it down any further to work out whether it's the linker, gcc or cpp or even the make engine?


Architecture: pentium4, Testing repos: Yes, Hardware: EeePC 901+2GB RAM+OS half on the SD card.

Offline

#19 2019-07-21 06:54:24

andreas_baumann
Administrator
From: Zurich, Switzerland
Registered: 2017-08-10
Posts: 755
Website

Re: [SOLVED] linker error (glibc bug)

binutils changelogs say:

        * cet.m4 (GCC_CET_FLAGS): Default to --disable-cet, replace
        --enable-cet=default with --enable-cet=auto.

so I try just to enable CET for binutils.

My theory is that gcc and glibc are producing CET code just fine (the patch in glibc was to eliminate
this CET-auto-thing, which can go wrong based on auto-probing and moon phases and replace it
with an excplicit --enable-cet). So binutils ld just doesn't known about this ELF section and throws
a warning.

What I don't get: upstream has _NO_ such flag in their PKGBUILD, so I think it works somehow by
accident on 64-bit (as CET is done differently?).

Offline

#20 2019-07-21 12:56:02

andreas_baumann
Administrator
From: Zurich, Switzerland
Registered: 2017-08-10
Posts: 755
Website

Re: [SOLVED] linker error (glibc bug)

Now I have the very interesting effect, that binutils 2.32-2.76 pentium4 seems not to throw the linker warning, but i686 is.
So there might be another thing lurking here.. :-)

Offline

#21 2019-07-21 13:47:27

jghodd
Member
Registered: 2019-07-14
Posts: 18

Re: [SOLVED] linker error (glibc bug)

@levi

i had already isolated gcc/gcc-libs, binutils, glibc, glib2 and gnutls to versions that predated the last glibc that produced no warnings. glib2, glibc and gnutls have been ruled out. glibc builds without warnings with the downgraded versions of gcc/gcc-libs and binutils. gcc/gcc-libs is still downgraded when i upgraded binutils to the latest version in core when the warnings returned. i know binutils is a collection of binary tools, but it's built as a unit so i'm not sure what exactly you're asking me to do. are you asking if i can just copy the older ld binary into /usr/bin after installing the current version of binutils? gcc, gcc-libs and glibc are already broken out. do remember it takes 8-10 hours for me to do a build. it's not really feasible for me to sub in older binutils binaries one at a tme until it works again. could take me 2 weeks and i'm thinking this is up to you guys to figure out the details. i'm only helping to narrow down which package is causing the issue. i will try the build with the latest staging release of binutils...

Offline

#22 2019-07-21 14:06:03

jghodd
Member
Registered: 2019-07-14
Posts: 18

Re: [SOLVED] linker error (glibc bug)

@andreas_baumann

so far no warnings using your latest staging build of binutils, Andreas. i should be seeing them by this point in the glibc build if they're going to happen. i;ll let the build complete so it'll be this evening before i can say for sure, but it looks good so far. thanks for the feedback. i did read your latest commit notes and saw what you had to do. interesting explanation.

Last edited by jghodd (2019-07-21 14:07:23)

Offline

#23 2019-07-21 14:45:11

jghodd
Member
Registered: 2019-07-14
Posts: 18

Re: [SOLVED] linker error (glibc bug)

@andreas_baumann

Ok. the combination of gcc-8.2.1+20181127-1.2, gcc-libs-8.2.1+20181127-1.2, glibc-2.29-1.23 and binutils-2.32-2.76 works fine. but if i upgrade gcc/gcc-libs and glibc, or even upgrade those to your latest staging builds, the warning returns. so we're not done yet. the binutils fix is correct, so lets firgure out what's next.

[Edit: i've downgraded gcc, gcc-libs and glibc again and will complete the upstream glibc build. then i'll try upgrading glibc and if that doesn;t work, i'll upgrade glibc to my self-build without warnings. i;ll let you know later tonight how it goes]

Last edited by jghodd (2019-07-21 15:00:18)

Offline

#24 2019-07-21 21:59:20

levi
Moderator
From: Yorkshire, UK
Registered: 2018-06-16
Posts: 389

Re: [SOLVED] linker error (glibc bug)

jghodd wrote:

@levi
i know binutils is a collection of binary tools, but it's built as a unit so i'm not sure what exactly you're asking me to do. are you asking if i can just copy the older ld binary into /usr/bin after installing the current version of binutils? gcc, gcc-libs and glibc are already broken out. do remember it takes 8-10 hours for me to do a build. it's not really feasible for me to sub in older binutils binaries one at a tme until it works again. could take me 2 weeks and i'm thinking this is up to you guys to figure out the details. i'm only helping to narrow down which package is causing the issue. i will try the build with the latest staging release of binutils...

Yeah, I can't think of any other way to try this out, so fair enough if it's beyond the scope of what you're trying here.


Architecture: pentium4, Testing repos: Yes, Hardware: EeePC 901+2GB RAM+OS half on the SD card.

Offline

#25 2019-07-21 23:33:44

jghodd
Member
Registered: 2019-07-14
Posts: 18

Re: [SOLVED] linker error (glibc bug)

@andreas_baumann

bad news on the binutils front. using gcc-8.2.1+20181127-1.2, gcc-libs-8.2.1+20181127-1.2, glibc-2.29-1.23 and binutils-2.32-2.76, and building the entire glibc upstream package, the warnings have returned. i must've checked for the warnings too early on the last try of this combination. interestingly, however, my build of calamares that started all of this, builds just fine with this particular mix of package versions. so you fixed something in binutils, but something else is still not quite right.

Offline

Board footer

Powered by FluxBB