Pierre Labastie wrote:
> Now I have done it, but I do not fully understand what is going on.
> The comparison between current build and Jeremy's is done in ICA style:
> First remove all symlinks,
> Then extract archives into a directory with the same name
> Then stripping ".o" files from debug symbols
> and all other binary files from all symbols
> Then diffing the directories.
> Here is the result (skipping obvious difference due to times stamps
> or random bits used in groff documentation or differences in info/dir):
> ASCII FILES diff:
> -----------------------------------------------------------------------------------------------------
> diff -ur LFS-TEST.TRUNK/usr/lib/libgmpxx.la 
> LFS-TEST.SYSROOT/usr/lib/libgmpxx.la
> --- LFS-TEST.TRUNK/usr/lib/libgmpxx.la  2012-03-17 15:27:52.000000000 +0100
> +++ LFS-TEST.SYSROOT/usr/lib/libgmpxx.la        2012-03-17 
> 16:28:39.000000000 +0100
> @@ -17,7 +17,7 @@
>   inherited_linker_flags=''
> 
>   # Libraries that this one depends upon.
> -dependency_libs=' /usr/lib/libgmp.la /usr/lib/libstdc++.la'
> +dependency_libs=' /usr/lib/libgmp.la /usr/lib/../lib64/libstdc++.la'

This is vaguely concerning for a pure64 build, but is correct for
multilib, so eh, whatever.

> diff -ur LFS-TEST.TRUNK/usr/lib/libmpc.la LFS-TEST.SYSROOT/usr/lib/libmpc.la
> --- LFS-TEST.TRUNK/usr/lib/libmpc.la    2012-03-17 15:28:22.000000000 +0100
> +++ LFS-TEST.SYSROOT/usr/lib/libmpc.la  2012-03-17 16:29:09.000000000 +0100
> @@ -17,7 +17,7 @@
>   inherited_linker_flags=''
> 
>   # Libraries that this one depends upon.
> -dependency_libs=' /usr/lib/libmpfr.la /usr/lib/libgmp.la -lm'
> +dependency_libs=' /usr/lib/libmpfr.la /usr/lib/libgmp.la 
> /usr/lib/libgmp.la -lm'

Multiple copies of libgmp.la; that's an accomplishment.  :-)

>   # Names of additional weak libraries provided by this library
>   weak_library_names=''
> ---------------------------------------------------------------------------------------------------
> For binary files, I only list files for which readelf -a or objdump -x 
> -s differ.
> First, all the grub modules differ:

Weird, but hopefully not a problem?  Grub is run far outside the system,
at least.

> A diff of objdump -x -s results give:
> diff -u acpi.mod.TRUNK acpi.mod.SYSROOT
> --- acpi.mod.TRUNK      2012-03-17 18:30:01.000000000 +0100
> +++ acpi.mod.SYSROOT    2012-03-17 18:29:50.000000000 +0100
> @@ -1,6 +1,6 @@
> 
> -LFS-TEST.TRUNK/usr/lib/grub/i386-pc/acpi.mod:     file format elf32-i386
> -LFS-TEST.TRUNK/usr/lib/grub/i386-pc/acpi.mod
> +LFS-TEST.SYSROOT/usr/lib/grub/i386-pc/acpi.mod:     file format elf32-i386
> +LFS-TEST.SYSROOT/usr/lib/grub/i386-pc/acpi.mod

That diff is purely the source filenames, right?  (Just so I understand
what I'm looking at...)

> @@ -9,17 +9,17 @@
>   Idx Name          Size      VMA       LMA       File off  Algn
>     0 .text         00001030  00000000  00000000  00000034  2**2
>                     CONTENTS, ALLOC, LOAD, READONLY, CODE
> -  1 .rel.text     00000000  00000000  00000000  00001da0  2**2
> +  1 .rel.text     00000000  00000000  00000000  00001064  2**2
> 
> I seems that relocation data is at the end of the file in the TRUNK case
> while they follow the relevant section in the SYSROOT case. I cannot say 
> why...

Different flags sent to the linker?  Bug in the new setup?  (Bug in the
old setup?  :-) )

I'm not sure if either is more "correct" though.

Do you know offhand how the grub2 modules are built?

> Then some of the archives (libc_nonshared, libpthread_nonshared) 
> installed by glibc contain
> ".oS" files, which have the same type of differences (relocation data
> at the end of the file or of the section for TRUNK or SYSROOT respectively).

*Possibly* "shared .o file", that is, "compiled with -fPIC"?  I'm
guessing here, though.

Oh, wait.  *Both* installation methods include the files, but their
contents are different in the same way that the grub modules' contents
are different?  That's less of an issue I think.  (At first I thought
you meant the .oS files didn't exist in the current book's output.)

It'd be good to track this down, I think.

> Then libgmpxx.so.4.2.4 has and rpath of /usr/lib/../lib64 in the SYSROOT 
> case
> while it has no rpath in the TRUNK case: same problem as between the first
> and second build of ICA in the TRUNK case. Means the sysroot case
> builds chapter 6 closer to a second TRUNK build.

Yep, I'd agree there.  The extra RPATH doesn't hurt, since we have the
lib64 -> lib symlink, and is needed on a multilib setup.

> I am not sure I fully understand this story of relocation data...

I'd have to guess different flags sent to the linker.  As for *why*
those flags are being sent differently... no idea yet.  :-)  I should
get some hardware and start rebuilding to poke into this.

Attachment: signature.asc
Description: OpenPGP digital signature

-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Reply via email to