[patch] update glibc to 2.35

Hello! I have decided I wanted to work on updating glibc. I tested the updated glibc with the packages ‘hello’, ‘coreutils’, ‘grep’, ‘sed’ and ‘guile’, and they all built successfully!

I have attached the generated ‘git diff’ to this message, and I hope that is fine. If there are any issues, please feel free to let me know!

zamfofex schreef op za 09-04-2022 om 22:16 [-0300]:

+                     (define empty-static-libraries '("libpthread.a"

"libdl.a" "libutil.a" "libanl.a"))

+                     (define (empty-static-library? file)

+                       (any (lambda (s) (string=? file s)) empty-

static-libraries))

+

                      (define (static-library? file)

                        ;; Return true if FILE is a static library. 

The

                        ;; "_nonshared.a" files are referred to by

libc.so,

                        ;; libpthread.so, etc., which are in fact

linker

                        ;; scripts.

                        (and (string-suffix? ".a" file)

-                            (not (string-contains file

"_nonshared"))))

+                            (not (string-contains file

"_nonshared"))

+                            (not (empty-static-library? file))))

Why are empty static libraries skipped? Would "gcc -static -lpthread main.c" (*)

(in an environment that includes glibc:static) still work, or does it now fail?

Greetings,

Maxime.

zamfofex schreef op za 09-04-2022 om 22:16 [-0300]:

An explanation and a link to an upstream report is mising.

(apparently upstream=Guix here?).

Greetings,

Maxime.

zamfofex schreef op za 09-04-2022 om 22:16 [-0300]:

What's the reason for this patch?

Greetings,

Maxime.

They are skipped from being moved, but then should be copied in the loop immediately below it.

I’m not sure if there is a report yet. There is a conversation in IRC, however. See:

- https://logs.guix.gnu.org/guix/2022-04-09.log#081848

- https://logs.guix.gnu.org/guix/2022-04-09.log#082442

- https://logs.guix.gnu.org/guix/2022-04-09.log#171259

- https://logs.guix.gnu.org/guix/2022-04-09.log#174339

‘/bin/sh’ doesn’t seem available in the build environment, so tests were failing. From what I was able to see, that macro is only used in tests, so I didn’t think it would be worthwhile to make it refer to ‘/gnu/store/.../bash’.

- - - - - - -

Apologies to Maxime for the repeated messages, and to others for taking so long to reply. Apparently I hadn’t replied to the debbugs address, so my initial messages were sent only to Maxime.

I hope this can be looked into soon enough!

Hello!

zamfofex <zamfofex@twdb.moe> skribis:

Yay!

Could you confirm that these patches are no longer needed?

[...]

Like Maxime wrote, this needs comments in the code.

Could you explain why the empty .a files need special treatment? In the

end, it seems we’re copying them to the “static” output anyway, so why

not let them in ‘files’?

This should be done in a separate patch.

Like Maxime wrote, please start the patch with a short comment

explaining what it does, and with a link to the upstream commit or bug

report.

One last thing: could you use ‘git format-patch’ and (optionally) ‘git

send-email’ to send a revised patch?

https://guix.gnu.org/manual/devel/en/html_node/Submitting-Patches.html

Thanks in advance, and apologies for the delay!

Ludo’.

I don’t remember exactly what my thought process was for removing the ‘glibc-dl-cache’ patch except that it wasn’t applicable anymore. At any rate, I don’t fully understand what the patch is actually doing, so it’s a bit difficult to assess whether it’s still necessary to me. (Help would be appreciated!)

Other than that, I did verify the other two patches, and it seems the regexes they were patching have already been fixed upstream!

Those files need to be present in both the ‘static’ and ‘out’ outputs, whereas without considering them specially, they would be moved to the ‘static’ output (with ‘rename-file’ as opposed to ‘copy-file’). Is a comment worthwhile? What should I write? I could explain the change in glibc that made those into empty ‘.a’ files and link to the changelog. Is that enough?

That is fine. Though I will note that the previous version of m4 did not work with the updated glibc, so I think it would make sense to updated it *before* updating glibc in the commit history. Do I need to verify whether the newer version works with the previous glibc too?

I’m still confused about what I should link to. I can write a comment explaining the issues and link to the IRC conversation we held, or maybe even to this thread. But I don’t think there actually is “an upstream commit or bug report” that I could link to.

I definitely don’t mind investigating using those tools more carefully! I think I can prepare and send another patch once my questions are clarified.

- - -

Apologies to Maxime and Ludovic for the repeated messages once again and to others for taking so long to respond. I’m still getting familiar with sending emails properly!

At any rate, thank you for looking into it!

Hi!

Sorry for the long delay.

zamfofex <zamfofex@twdb.moe> skribis:

There’s a comment at the top of ‘glibc-dl-cache.patch’ that explains

what it does, but see

for details. I can take a look and update it.

Great.

Why?

We’d need a comment like “Keep empty .a files in OUT in addition to

STATIC because …”.

Ideally yes.

When applying a patch to a package, we seek to document the reason why

we’re doing it, to ease maintenance; usually, patches come from a bug

report or from a change upstream, so we would like to it.

Perfect. I realize upgrading glibc is a rather tricky task, so thanks

for giving it a try! Surely we can team up to get it past the finish

line.

Thanks!

Ludo’.

It seems we both misinterpreted the diff I had sent originally, as that patch has not actually been removed, but rather its line was changed (it was moved upwards). So good news, no need for changes or further investigation!

I added a comment explaining the change! I hope it is enough.

Apparently M4 has already been updated in core-updates by now! So that all of that has already been resolved.

Thanks for the encouragement! However, since glibc 2.36 releases a few weeks from now, do you feel like it would make sense to wait until then to update it? I suppose it could always be updated again later, but I don’t know if that’s ideal.

- - -

Also, I could not figure out how to use ‘git prepare-patch’ or ‘git send-email’ properly, so I hope a ‘git diff’ attachment is enough.

On Tue, Jul 19, 2022 at 12:14 PM zamfofex <zamfofex@twdb.moe> wrote:

I have used your patch to bootstrap with GCC 12 (in order to use both

gcc-12 and llvm-14 in the same profile) and I have found that without

"glibc-ldd-x86_64.patch", sometimes ldd will throw a "not a dynamic

executable" error. I assume the powerpc patch is likewise still

required.

I would like to see the 2.35 upgrade since others may benefit before

the 2.36 release and in case of a core-updates merge to master.

Greg

Greg Hogan <code@greghogan.com> skriver:

I submitted a variant of this patch to #57533 that preserves

glibc-ldd-x86_64.patch.

Closing this issue, as it has been superseded by #57533.

Thanks zamfofex!