Opened 5 years ago

Closed 5 years ago

#4085 closed defect (fixed)

Version changes break Stripping Again.

Reported by: ken@… Owned by: lfs-book@…
Priority: normal Milestone: 8.1
Component: Book Version: SVN
Severity: normal Keywords:


In the current book we run objcopy on various libs. Changes in the last few days mean that 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.

Change History (7)

comment:1 by ken@…, 5 years ago

Owner: changed from lfs-book@… to ken@…
Status: newassigned

comment:2 by ken@…, 5 years ago

Owner: changed from ken@… to lfs-book@…
Status: assignednew

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.

comment:3 by Armin, 5 years ago

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/
objcopy --only-keep-debug $F $F.dbg 
strip --strip-unneeded $F
objcopy --add-gnu-debuglink=$F.dbg $F
$ readlink -f /usr/lib/

comment:4 by bdubbs@…, 5 years ago

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

What happens when, for instance becomes 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.

comment:5 by Armin, 5 years ago

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.

comment:6 by bdubbs@…, 5 years ago

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

comment:7 by bdubbs@…, 5 years ago

Resolution: fixed
Status: newclosed

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.

Note: See TracTickets for help on using tickets.