Version changes break Stripping Again.

[ken@…]

In the current book we run objcopy on various libs. Changes in the last few days mean that libstdc++.so.6.0.22 is now .23, and the libmpx variants mentioned are 2.0.1 not 2.0.0 : this causes the command to fail.

Unfortunately, tieing the versions to changed source is hard. As an initial workaround I'll hardcode the immediate fixes, but I wonder if we could set up entities for EACH of the packages here (GLIBCFULL, MPXFULL, LIBTHREADDBFULL, LIBQUADMATHFULL, etc) and define those immediately after the version of the relevant package with a comment that they are for 'Stripping Again'.

This is just an attempt to stop it breaking next time one of the affected packages gets updated.

[ken@…]

Initial fix at r11249, passing back to lfs-book for discussion.

I will note that I still can't actually strip the progs (similar error to before), but I've separated the creation of the debug symbols and put that at the end of my chapter 6 script which is how I came to notice this.

An alternative way to flag up the problem via jhalfs might be to separate the creation of debug symbols so that it is always run - that will break the build when versions change.

[Armin]

I've always disliked using hardcoded versions in instructions, unless they're specifically tied to package version and can be accomodated by using &foo-version;

This might be better (adjust properly for the instructions)

F=$(readlink -f /usr/lib/libstdc++.so)
objcopy --only-keep-debug $F $F.dbg 
strip --strip-unneeded $F
objcopy --add-gnu-debuglink=$F.dbg $F

$ readlink -f /usr/lib/libstdc++.so
/usr/lib/libstdc++.so.6.0.23

[bdubbs@…]

The idea of a script is good, but it then becomes complicated. Just looking at the four files in /lib, we have

ld-linux-x86-64.so.2 -> ld-2.25.so
libpthread.so.0 -> libpthread-2.25.so
libthread_db.so.1 -> libthread_db-1.0.so
libc.so.6 -> libc-2.25.so

What happens when, for instance libpthread.so.0 becomes libpthread.so.1? We still have the issue of hard coding in the symlink name itself.

We could have ENTITIES for each of the 11 files, but does that really add much as they are still essentially hard coded. It would not help to put them in the package pages as they are not propagated to the rest of the book. They would need to be in a file like packages.ent. Actually, that might be a reasonable place as they would be obvious candidates for checking/update when the associated package is updated.

[Armin]

Using versions in mentioned libs is fine, they match glibc versions. Changing sonames in glibc would mean total breakage and probably glibc-3. Not to mention glibc sonames haven't changed in two decades now. My suggestion was for gcc libraries, where they bump libtool versions, so you have, eg, so.6.1.1, so.6.1.2, and such.

[bdubbs@…]

I updated the book adding entities to packages.ent. I'll leave the ticket open for a while though.

[bdubbs@…]

It's been two weeks.

I'm going to close this as fixed. If the issue comes up again, reopen or create a new ticket.