View previous topic :: View next topic |
Author |
Message |
transpetaflops Apprentice
Joined: 16 May 2005 Posts: 159
|
Posted: Tue Jul 28, 2009 5:04 pm Post subject: lafilefixer clarifications |
|
|
This has bothered me for some time now so I'll just have to ask. After upgrading libpcre some time ago the elog output instructed me to install lafilefixer and run "lafilefixer --justfixit". Doing so, it found some files it updated without any errors.
Q1. What exactly is this utility and what are the implications of NOT running it as instructed?
Q2. Running this utility after a world update almost always seems to find a few more files to update. Is running this utility supposed to become a part of my normal world update routine from now on and couldn't the functionality be merged into emerge instead if this is the case?
Q3. Looking at the help, the "--justfixit" seems to limit the utility to a few pre-defined directories. Should I run it without any parameters at some point to scan through my complete filesystem?
Thanks in advance for your input.
/PP |
|
Back to top |
|
|
Mike Hunt Watchman
Joined: 19 Jul 2009 Posts: 5287
|
Posted: Tue Jul 28, 2009 5:56 pm Post subject: |
|
|
Is it just my imagination, or does my whole system seem to be responding very much better/faster after running that? |
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6747
|
Posted: Tue Jul 28, 2009 6:59 pm Post subject: Re: lafilefixer clarifications |
|
|
transpetaflops wrote: | Q1. What exactly is this utility and what are the implications of NOT running it as instructed? |
As the name says, it fixes *.la files. These are files used by libtool. More precisely, if you install library B which in turn uses library A, then library B will store this information in an *.la file. Now if something links against library B, it uses this information. If the information stored in the *.la file is not up-to-date with your actual system, this linking against library B can fail. Typically, you will see a (hard to understand) error during emerge when the library should be linked.
Quote: | Is running this utility supposed to become a part of my normal world update routine from now on and couldn't the functionality be merged into emerge instead if this is the case? |
I hope very much that this will never be included in emerge - it is bad enough that a special case thereof is already contained in the gcc eclass. The problem is that it is always very bad to change files after their installation (their checksum will be false, and so e.g. you can never tell whether the change was intentional or by some damage or even by some intentional corruption).
The better solution is to manually reemerge the packages with the broken *.la files. However, this can be tricky, since portage's dependency tracking will usually fail in such a situation which means that you might have to manually change the order of the packages to reemerg - which needs some knowledge and inspection of the *.la files. Probably many users would not be able to do this manually. (But this does not mean that forcing the modification for users would be a good thing.) |
|
Back to top |
|
|
Mike Hunt Watchman
Joined: 19 Jul 2009 Posts: 5287
|
Posted: Tue Jul 28, 2009 7:54 pm Post subject: |
|
|
How does one find packages with the broken *.la files without lafilefixing them? |
|
Back to top |
|
|
transpetaflops Apprentice
Joined: 16 May 2005 Posts: 159
|
Posted: Tue Jul 28, 2009 8:12 pm Post subject: |
|
|
I searched bugzilla and found only few reports that might be related to this so I guess it isn't a very big problem. One bug report suggested revdep-rebuild to take care of this instead. Some official best practices would be nice to have from the Gentoo team. |
|
Back to top |
|
|
transpetaflops Apprentice
Joined: 16 May 2005 Posts: 159
|
Posted: Tue Jul 06, 2010 11:46 am Post subject: |
|
|
Bumping this old thread because I wanted to direct your attention to a blog post by Diego:
http://blog.flameeyes.eu/2010/05/12/gentoo-failed-us-again
As I suspected, lafilefixer is referenced by more and more elog outputs these days and Diego recommends adding the following to /etc/portage/bashrc to automatically run lafilefixer after every merged package:
Code: | post_src_install() {
lafilefixer "${D}"
} |
A nice trick to help people keep out of trouble with the la-files. |
|
Back to top |
|
|
Voltago Advocate
Joined: 02 Sep 2003 Posts: 2593 Location: userland
|
Posted: Tue Jul 06, 2010 12:18 pm Post subject: |
|
|
I'm wondering: Isn't it possible to get rid of the current static library format completely, and statically link .so files? Probably some changes would be necessary to the shared ELF object format, but is there a practical reason why two different formats are needed? (apart from legacy/compatibility reasons) |
|
Back to top |
|
|
transpetaflops Apprentice
Joined: 16 May 2005 Posts: 159
|
Posted: Tue Jul 06, 2010 12:46 pm Post subject: |
|
|
Diego has fought long and hard with the other developers to drop la-files entirely. It's obviously a very infected issue so I'll stay out of it |
|
Back to top |
|
|
Voltago Advocate
Joined: 02 Sep 2003 Posts: 2593 Location: userland
|
Posted: Tue Jul 06, 2010 12:52 pm Post subject: |
|
|
transpetaflops wrote: | Diego has fought long and hard with the other developers to drop la-files entirely. It's obviously a very infected issue so I'll stay out of it |
I was more thinking about dropping .a files (and .la files too, of course). |
|
Back to top |
|
|
transpetaflops Apprentice
Joined: 16 May 2005 Posts: 159
|
|
Back to top |
|
|
few Guru
Joined: 03 Mar 2008 Posts: 448
|
Posted: Tue Dec 28, 2010 4:16 pm Post subject: |
|
|
I guess his nightmare is about emerge running the lafilefixer script every now and then, but that's not what emerge does. emerge runs it's own version of the script over the image, before files are installed into the system and checksums are taken. This means that it does not modify already installed files. |
|
Back to top |
|
|
transpetaflops Apprentice
Joined: 16 May 2005 Posts: 159
|
Posted: Tue Dec 28, 2010 5:00 pm Post subject: |
|
|
Actually, my test from yesterday suggests it's the other way around. Below is a diff from emerging libxcb. The left column is from Diego's method, using lafilefixer, and clearly updates the la-files in the /tmp folder before installing. The right column is the output from using the Portage based python script and suggests the la-files are updated after being copied to their correct location in the fs. But the full path isn't shown there so I may be wrong. I don't know if this matters in any way though. The important thing is to let people know that they can uninstall lafilefixer and that they shouldn't have to run it manually ever again after doing an emerge -e world.
Code: | Calculating dependencies... done! | Calculating dependencies... done!
/tmp/portage/x11-libs/libxcb-1.7/image/usr/lib64/libxcb-xvmc.la: Updating... | Fixing .la files
/tmp/portage/x11-libs/libxcb-1.7/image/usr/lib64/libxcb-xv.la: Updating... | usr/lib64/libxcb-xvmc.la
/tmp/portage/x11-libs/libxcb-1.7/image/usr/lib64/libxcb-xtest.la: Updating... | usr/lib64/libxcb-xv.la
/tmp/portage/x11-libs/libxcb-1.7/image/usr/lib64/libxcb-xprint.la: Updating... | usr/lib64/libxcb-xtest.la
/tmp/portage/x11-libs/libxcb-1.7/image/usr/lib64/libxcb-xinput.la: Updating... | usr/lib64/libxcb-xprint.la
/tmp/portage/x11-libs/libxcb-1.7/image/usr/lib64/libxcb-xinerama.la: Updating... | usr/lib64/libxcb-xinput.la
/tmp/portage/x11-libs/libxcb-1.7/image/usr/lib64/libxcb-xfixes.la: Updating... | usr/lib64/libxcb-xinerama.la
/tmp/portage/x11-libs/libxcb-1.7/image/usr/lib64/libxcb-xf86dri.la: Updating... | usr/lib64/libxcb-xfixes.la
/tmp/portage/x11-libs/libxcb-1.7/image/usr/lib64/libxcb-xevie.la: Updating... | usr/lib64/libxcb-xf86dri.la
/tmp/portage/x11-libs/libxcb-1.7/image/usr/lib64/libxcb-sync.la: Updating... | usr/lib64/libxcb-xevie.la
/tmp/portage/x11-libs/libxcb-1.7/image/usr/lib64/libxcb-shm.la: Updating... | usr/lib64/libxcb-sync.la
/tmp/portage/x11-libs/libxcb-1.7/image/usr/lib64/libxcb-shape.la: Updating... | usr/lib64/libxcb-shm.la
/tmp/portage/x11-libs/libxcb-1.7/image/usr/lib64/libxcb-screensaver.la: Updating... | usr/lib64/libxcb-shape.la
/tmp/portage/x11-libs/libxcb-1.7/image/usr/lib64/libxcb-res.la: Updating... | usr/lib64/libxcb-screensaver.la
/tmp/portage/x11-libs/libxcb-1.7/image/usr/lib64/libxcb-render.la: Updating... | usr/lib64/libxcb-res.la
/tmp/portage/x11-libs/libxcb-1.7/image/usr/lib64/libxcb-record.la: Updating... | usr/lib64/libxcb-render.la
/tmp/portage/x11-libs/libxcb-1.7/image/usr/lib64/libxcb-randr.la: Updating... | usr/lib64/libxcb-record.la
/tmp/portage/x11-libs/libxcb-1.7/image/usr/lib64/libxcb-glx.la: Updating... | usr/lib64/libxcb-randr.la
/tmp/portage/x11-libs/libxcb-1.7/image/usr/lib64/libxcb-dri2.la: Updating... | usr/lib64/libxcb-glx.la
/tmp/portage/x11-libs/libxcb-1.7/image/usr/lib64/libxcb-dpms.la: Updating... | usr/lib64/libxcb-dri2.la
/tmp/portage/x11-libs/libxcb-1.7/image/usr/lib64/libxcb-damage.la: Updating... | usr/lib64/libxcb-dpms.la
/tmp/portage/x11-libs/libxcb-1.7/image/usr/lib64/libxcb-composite.la: Updating... | usr/lib64/libxcb-damage.la
/tmp/portage/x11-libs/libxcb-1.7/image/usr/lib64/libxcb.la: Updating... | usr/lib64/libxcb-composite.la
> usr/lib64/libxcb.la
|
|
|
Back to top |
|
|
|