all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Guillaume Le Vaillant <glv@posteo.net>
To: Leo Famulari <leo@famulari.name>
Cc: guix-devel@gnu.org
Subject: Re: [core-updates-frozen] Bug in binutils 2.37
Date: Tue, 07 Sep 2021 16:38:34 +0000	[thread overview]
Message-ID: <87o894iad7.fsf@kitej> (raw)
In-Reply-To: <YTeRa6yyR1k0KXez@jasmine.lan>

[-- Attachment #1: Type: text/plain, Size: 2530 bytes --]

Leo Famulari <leo@famulari.name> skribis:

> On Mon, Sep 06, 2021 at 03:39:52PM +0000, Guillaume Le Vaillant wrote:
>> There's a bug in binutils 1.37, which we are using on the
>> core-updates-frozen branch.
>
> 2.37, right? :)
>

Indeed. :)


>> It's a file descriptor leak that can lead to 'malformed archive' errors
>> when linking libraries. We get this problem at least when building
>> qtwekbit and qtwebengine. A workaround allows us to compile qtwebkit
>> (see [1]), but it doesn't work for qtwebengine.
>> 
>> The bug was discussed at [2] and upstream has a patch to fix it at [3].
>> However, adding this patch to our binutils rebuilds the world.
>> I'm currently trying to build things with the patched binutils.
>> If everything works, should I push this fix on core-updates-frozen, or
>> does someone have an idea that would lead to less rebuilds?
>
> There are a few options:
>
> 1) Apply the patch in the normal way and rebuild the world. If the
> changes in the patch are limited to fixing this bug, then we can be
> confident that changing binutils will not break other packages, which is
> the main goal behind "freezing" the core-updates branch. Do you think
> that expectation is reasonable? Otherwise, the branch is frozen except
> for bug fixes; we'd like to avoid rebuilding the world but it's not a
> problem if we have to.
> 2) Create a binutils-fixed package and only use it for qtwebkit and
> qtwebengine
> 3) Try to work around the bug in the qtwebkit and qtwebengine packages
>
> 2 and 3 are not great because maybe the bug affects other packages in
> some situations. Do you know if it manifests deterministically?

The problem happens when linking a library with a lot of members (I
don't know exactly how many), which is the case at least for qtwebkit
and qtwebengine. Users creating such libraries in their projects will
also have the problem.

Increasing the maximum number of open file descriptors seems not be
a very robust workaround. Setting it at 4096 for qtwebkit works,
but I tried 4096, 8192 and 16384 for qtwebengine and it didn't work.

I have built many packages with the patched binutils and I didn't get
any new failure so far. I'm not yet at qtwebkit and qtwebengine though
(compiling the 20 versions of rust took a while).
So when I get there, and if the patch really solves the issue, pushing
it looks like the best solution.

Do you know if there are other world-rebuilding pending fixes that could
go in at the same time?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

  reply	other threads:[~2021-09-07 17:06 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-06 15:39 [core-updates-frozen] Bug in binutils 1.37 Guillaume Le Vaillant
2021-09-07 16:20 ` Leo Famulari
2021-09-07 16:38   ` Guillaume Le Vaillant [this message]
2021-09-08 12:50     ` [core-updates-frozen] Bug in binutils 2.37 Guillaume Le Vaillant

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87o894iad7.fsf@kitej \
    --to=glv@posteo.net \
    --cc=guix-devel@gnu.org \
    --cc=leo@famulari.name \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.