Readjusted linker issues etc.
thekevinday at gmail.com
Wed May 20 14:57:13 PDT 2009
On Sun, May 17, 2009 at 8:09 PM, robert baker <robertmbaker at gmail.com> wrote:
> As I mentioned the other day I did go ahead and build the temp system
> again. This time I used linux-18.104.22.168 along with the corresponding
> grsec patch. I have had no issues I can trace back to the kernel
> includes. So at least early on that looks good.
> I was experiencing problems with the re-adjusted linker before I
> rebuilt the temporary system, but didn't look at it much because I was
> trying to document the reboot procedure. These same issues did crop
> back up on my latest rebuild. Taking a look at the ld-new that we
> copy into /tools/bin during binutils-pass2 I found it was considerably
> smaller than expected. Reading the file with a text editor shed some
> light on my problems.
> # ld-new - temporary wrapper script for .libs/ld-new
> # Generated by ltmain.sh (GNU libtool 1.2435 2007/03/18 18:44:42) 2.1a
> # The ld-new program cannot be directly executed until all the libtool
> # libraries that it depends on are installed.
> # This wrapper script should never be moved out of the build directory.
> # If it is, it will not operate correctly.
> Going back to my binutils obj/ directory and executing the below
> commad installed a working re-adjusted linker.
> make -C ld install
> Robert Baker
This has happened to me on seemingly random occasions (though I very
much doubt its random).
The problem seems to be related to how they create a wrapper script to
call their binary that they hide inside of their source code
They "hide" the actual binary in ld/.libs/ld-new (the libs has a
period before it).
I could never understand why they would want to hide a binary in such a way..
I've added the following command to my scripts to handle the case
should it happen:
if [ -e ld/.libs/ld-new ] ; then cp -v ld/.libs/ld-new bin/ ; else cp
-v ld/ld-new /bin/ ; fi
More information about the hlfs-dev