[Patch: RFC] Log new files

George Boudreau georgeb at linuxfromscratch.org
Mon Apr 30 17:53:31 PDT 2007

M.Canales.es wrote:
> El Jueves, 26 de Abril de 2007 23:41, Matthew Burgess escribió:
>> Hi guys.
>> At the moment, Jhalfs doesn't track what files are installed by each
>> package it installs.  This causes me problems when upgrading packages in
>> LFS, as I can't easily figure out if there are any new binaries or
>> libraries that need adding to the book.
> Committed a first try in r3353. It's based in part on your patch but without 
> touching XSL code and adding a configuration option to enable it.
> The configuration option is under "Build Settings" menu above the test-suite 
> settings. It's off by default.
> Can you test if it work as expected?
   I have finished a LFS-svn build with the latest jhalfs. The logging 
of  the installed files added an additional ~1mb to jhalfs directory. If 
you are looking for reams of file information you will be satified with 
the contents of ./installed-files.
> Note that this feature will log the actual files created/installed by the book 
> commands included the ones created before configuring the package, if any, 
> not only the files installed by the package "make install".
> But that is also true in part for your patch, that logs the files moved or 
> linked by the book commands placed after a "make install" instead of logging  
> the actual files that will be installed by a plain "make install". 
> That meant that to verify if that move/linking commands are still needed you 
> will have to review the build log and/or build the package manually using a 
> DESTDIR approach (like until now).

Side issue:

   My first build failed when I tried the latest jhalfs.( build/test of 
gcc-pass2 failed )  At first I thought it was something in the Makfile 
so I reverted to jhalfs-2.2 and had the same problem. I did a build of 
LFS_6.2 and the build completed as normal. I then assumed there was a 
problem with LFS-svn. The test code in gcc-pass2 was linking against 
/lib/ld-linux-so.2 and not /tools/....  A /tools/bin/cc -dumpspecs said 
the dynamic linker was /tools/lib/ld-linux-so.2 . I put traces in the 
bash script to echo the path and dumpspecs. I finally found the problem 
when I did a test build with cc -v .  The first line of the trace 
indicated GCC was pulling in the specs file from the host at 
/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/specs  .

   Why did LFS-6.2 work and not LFS-svn? LFS-6.2 uses gcc-4.0.3 and 
LFS-svn is using gcc-4.1.2 (the same as the host) It seems gcc goes 
looking for the specs file using the search path (-print-search-dirs). 
Although there is no specs file in the /tools/... path 
usr/{lib,libexec}/gcc/i686-pc-linux-gnu/... is defined and gcc found a 
specs file on the host and caused the compile test to fail.  I renamed 
the specs file and a build of LFS-svn ran to completion.

  Lesson learned:
    GCC search paths can bite your when you least expect it.

More information about the alfs-discuss mailing list