pure64 library linking question

Ken Moffat ken at linuxfromscratch.org
Sun Oct 30 13:53:51 PST 2005


On Sun, 30 Oct 2005, Ryan Twitchell wrote:

> I've just built a system using the x86_64-64 version of the LFS book.
> Somehow, some (not all) of my libraries ended up installing in /lib64,
> as well as /usr/lib64 and /usr/X11R6/lib64. All these directories are
> symlinks to their respective plain 'lib' folders; so for each tree
> everything is essentially in the same directory. A few libraries seem
> to have been linked to programs through lib64.
>
  Ouch!  X sounds like you are missing some of the three necessary 
defines (check the lfs-dev archives from Friday).  But, you are clearly 
well into BLFS territory - depending on what packages you choose to 
build, in pure64 blfs you might be the first person who has tried them..

> My concern is how this could affect my system in the long run (The
> phrase "subtly broken toolchain" really made me nervous when reading
> the LFS book for the first time). I imagine the only real way to fix it
> is to recompile anything linking through the lib64 directories, but I
> would greatly appreciate any suggestions on management of this little
> quirk.

  You really need to identify where things started to go wrong.  At the 
moment, all we can assume is that somewhere between the start of 
building the final system, and X, lib64 appeared on the scene.  But, if 
you have lib64 as a symlink to lib, everything will actually be put into 
lib and probably work fine.  So, what persuaded you to make those /lib64 
and /usr/lib64 symlinks ?

  Oh, and pure64 gcc is technically broken anyway, in that it can't 'make 
bootstrap' without some editing to stop it using lib64 for temporary 
tools ! (see my unofficial pure64 hint for how to fix that on gcc-3.4).

  At the end of the day, if your system can build everything you want in 
the blfs area, and build the cross-tools and temporary-system parts of 
your next system, it's good enough in my opinion.

  My initial assumption, for references to lib64 in Cross-LFS x86_64-64, 
is that the reader switched to the x86_64 (multilib) book.  However, I'm 
willing to believe that some of the linkages in the book *might* be 
wrong - on Friday I was fairly confused when I thought I was looking at 
the multilib book to do some editing, and found myself in pure64. 
Perhaps I just clicked on the wrong link in the overall index.html where 
you can select which book you want to read.  Evidence of errors in the 
book's linkages will be welcome.

>
> I performed 'ldd /usr/bin/* | grep lib64' on all the standard bin and
> lib directories. A lot of libraries and the glibc installed programs
> link ld-linux-x86-64.so.2 through /lib64. Though I do recall more than
> just that library being installed through the /lib64 directory
> originally.
>

  That part definitely sounds like an excursion into the multilib book.

> I did perform the toolchain adjustment in the book. 'gcc -dumpspecs |
> grep lib64' yields nothing now, though there are a few lines about
> lib32 (there isn't such a directory).

  The pure64 specfile knows about lib32 because it came from debian amd64 
and it might yet turn out to be a good thing.

> Also, there doesn't seem to be an
> actual 'specs' file anywhere on my machine. Should one actually exist?
>

  From memory (I'm on a gcc-3.4.3 box at the moment), the specs file is 
only created under gcc-4 when it differs from the default values.  So, 
we run gcc -dumpspecs through a perl edit to sort out /tools/bin/gcc and 
create a specfile, but we don't need to create one for the final gcc.

Ken
-- 
  das eine Mal als Tragödie, das andere Mal als Farce


More information about the lfs-support mailing list