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.
--
http://linuxfromscratch.org/mailman/listinfo/alfs-discuss
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
