guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#47921] [PATCH] build: Fix elf-dynamic-info-soname.


From: Maxime Devos
Subject: [bug#47921] [PATCH] build: Fix elf-dynamic-info-soname.
Date: Wed, 21 Apr 2021 20:33:57 +0200
User-agent: Evolution 3.34.2

Dion Mendel schreef op wo 21-04-2021 om 23:46 [+0800]:
> Thanks for the follow up.
> 
> > 1. IIUC, this change would cause a world-rebuild, so this patch would 
> > have to applied on core-updates.  The subject line should have been
> > [PATCH core-updates]: etcetera.
> 
> Are you sure?  This patch will modify guix.
> 
>    guix graph --type=reverse-package guix
>
> Only shows a few packages to be rebuilt.  I am new to guix so I may be 
> wrong about this.

If this patch modified something in, say, guix/scripts or gnu/packages,
targetting "master" should be perfectly fine.  But this patch modifies
something under guix/build.  Modules under guix/build can be used from
the build environment, that is, from within the compilation process of
a package.  By modifying guix/build/gremlin.scm, a widely-used module
in package definitions (used indirectly via gnu-build-system IIRC),
practically all packages would be rebuilt.

Unless I'm severely mistaken, you can see this for yourself by:

0. start from a checkout of guix *without* your patch
1. # you probably have its dependencies already, but let's make sure
   ./pre-inst-env guix build hello
2. apply your patch to your local checkout of guix
3. make
4. ./pre-inst-env guix build hello
   # This will probably rebuild GCC, binutils, etc.!

> 2. How did you test this patch?
> 
> Tested in the repl.
> 
> Current behaviour:
> 
>     (elf-dynamic-info-soname
>       (call-with-input-file "/path/to/libz.so.1.2.11"
>                             (compose elf-dynamic-info parse-elf
>                                      get-bytevector-all)))
>     => #<<dynamic-entry> type: 14 value: "libz.so.1" offset: 5764>
> 
> There is no way to extract the value as dynamic-entry is private to the 
> module.
> 
> After the patch:
> 
>     (elf-dynamic-info-soname
>       (call-with-input-file "/path/to/libz.so.1.2.11"
>                             (compose elf-dynamic-info parse-elf
>                                      get-bytevector-all)))
>     => "libz.so.1"

So you didn't try to build any package with this patch?

I would recommend to make sure this patch doesn't break any packages.
While you can't test all packages (unless you have a *really big* build
farm), I would at least suggest running "./pre-inst-env guix build hello".
If that takes too long to complete, don't worry, just interrupt it and let
us now you couldn't test it completely.

To make sure this new functionality does not break in the future, please
write an unit test (in tests/gremlin.scm).

> > 3. What does this patch fix?
> 
> Module (guix build gremlin) exports several functions to extract 
> information from the dynamic section of an elf file.
> 
> elf-dynamic-info-soname is one of these functions.  It is not called 
> anywhere in guix.  I would like to use it for packaging, but it is 
> currently non functioning.

Your patch doesn't modify elf-dynamic-info-soname.  It modifies 
elf-dynamic-info.

> > 4. elf-dynamic-info-soname is a record accessor.  Did you mean 
> > elf-dynamic-info?

In case I wasn't clear, I was referring to the commit message.  In the commit
message, you say you modified elf-dynamic-info-soname, but you actually modified
elf-dynamic-info.
 
> No, I do not mean elf-dynamic-info.
See two comments above.

> elf-dynamic-info-soname is a record accessor which is currently broken 
Record accessors are correct by construction.  Perhaps you meant
that the "soname" field is initialised incorrectly by elf-dynamic-info?

> because it doesn't unwrap an internal structure, namely <dynamic-entry>.  
> All the other accessors unwrap this internal structure.
I think you can predict my response about accessors here (-:.

I'll interpret this as ‘in all other fields, the internal structure is 
unwrapped’.
That's a good point!  Your patch seems good to me, but the commit message 
doesn't
and it has a lack of testing.

> This patch brings this accessor into line with the others.

You didn't modify the elf-dynamic-info-soname, you modified elf-dynamic-info.
See comments above.

> > 5. According to the docstring (core-updates, 
> > c9a61dff8242612ae8275829a5ee31ff45ff08b1):
> > 
> >  "Return dynamic-link information for ELF as an <elf-dynamic-info> object, 
> > or
> >  #f if ELF lacks dynamic-link information."
> > 
> >  So this patch actually _introduces_ a bug.  Or you need to modify the 
> > docstring
> >  as well.

On second thought, the (revised) patch actually seems correct, and my comment 
here
doesn't make much sense.

> No.  This patch does not affect elf-dynamic-info.  It fixes one of its 
> accessors.

You modified elf-dynamic-info, so this patch does affect it.
elf-dynamic-info is a procedure, so it cannot have any accessors (unless you 
play
weird tricks with Guile's undocumented ‘applicable structs’).  The record is
<elf-dynamic-info>. <elf-dynamic-info> != elf-dynamic-info.

Greetings,
Maxime.

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

[Prev in Thread] Current Thread [Next in Thread]