转贴 CLFS ML 上的一个邮件。是关于 lib 目录查找定位的。

晨想

这个是问题：

When a package is building, how does it know where to find the
libraries? I haven't been able to find anywhere that manages to
explain it very well.

Normally I would expect make to go look in /lib, /usr/lib and
/usr/local/lib for libraries when compiling, but in the case of a
multilib system, there are libraries in /lib64, /usr/lib64, and
/usr/local/lib64 as well.  If make were to go immediately to the lib
variety (as opposed to lib64) it would not properly link in the case
of 64-bit compilation.  So, it must have another way to decide which
set of directories to go looking in.  I'd like to know how this is
accomplished.

To get packages to correctly located libraries do I always have to use
libdir=/lib64 or alter their makefiles - even if the package does not
compile any new libraries?  Do the  -m32 and -64 flags for gcc tell it
where to look?  Or is there some other way that the package determines
where to go hunting for libraries when it compiles?

Once compiled, I assume that a binary know what it needs to link to
based on what it was compiled with.  However, I want to make sure that
I understand how to properly deal with 64-bit libraries before I get
far into BCLFS so that I can avoid having problems like all of my
64-bit programs attempting to link against 32-bit libraries (or vice
versa).  Thanks for any help that you can give me.

- Jonathan Davis

晨想

这个是其中一篇答复。作者： Joe Ciccone.

Jonathan Davis wrote:
> > To get packages to correctly located libraries do I always have to use
> > libdir=/lib64 or alter their makefiles - even if the package does not
> > compile any new libraries?  Do the  -m32 and -64 flags for gcc tell it
> > where to look?  Or is there some other way that the package determines
> > where to go hunting for libraries when it compiles?
-m32 and -m64 affect the parameters passed to ld (linker). Your spec
file contains the info for how gcc links.

jciccone@sasquach ~ $ gcc -dumpspecs | grep link: -A1
*link:
%{!static:--eh-frame-hdr} %{!m32:-m elf_x86_64} %{m32:-m elf_i386}  
%{shared:-shared}   %{!shared:     %{!static:      
%{rdynamic:-export-dynamic}      
%{m32:%{!dynamic-linker:-dynamic-linker /lib/ld-linux.so.2}}      
%{!m32:%{!dynamic-linker:-dynamic-linker
/lib64/ld-linux-x86-64.so.2}}}     %{static:-static}}

the -m elf_x86_64 or -m elf_i386 is passed to the linker which chooses
which linker script to use. They're in  /usr/lib/ldscripts on both
multilib and non-multilib systems. Those linker scripts specify the
default search paths for libraries.

/usr/lib/ldscripts/elf_i386.x:6:SEARCH_DIR("/usr/i386-unknown-linux-gnu/lib");
SEARCH_DIR("/usr/local/lib"); SEARCH_DIR("/lib"); SEARCH_DIR("/usr/lib");
/usr/lib/ldscripts/elf_x86_64.x:6:SEARCH_DIR("/usr/x86_64-unknown-linux-gnu/lib64");
SEARCH_DIR("/usr/local/lib64"); SEARCH_DIR("/lib64");
SEARCH_DIR("/usr/lib64");
SEARCH_DIR("/usr/x86_64-unknown-linux-gnu/lib");
SEARCH_DIR("/usr/local/lib"); SEARCH_DIR("/lib"); SEARCH_DIR("/usr/lib");

The dynamic linker (runtime linker) is the only one with a hard-coded
path. It's a static library that loads the libraries found in the
executables header. The path to the dynamic linker is passed to ld when
linking also.

jciccone@sasquach ~ $ readelf -d /bin/bash

Dynamic section at offset 0x8c0b0 contains 24 entries:
  Tag        Type                         Name/Value
0x0000000000000001 (NEEDED)             Shared library:
[libreadline.so.5.1]
0x0000000000000001 (NEEDED)             Shared library: [libhistory.so.5.1]
0x0000000000000001 (NEEDED)             Shared library: [libncurses.so.5]
0x0000000000000001 (NEEDED)             Shared library: [libdl.so.2]
0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
[Snip 19 lines]

As for how ld-linux.so knows where to look for the libraries. A default
path is hard coded into the library (defaults to /lib:/usr/lib or
/lib64:/usr/lib64 or /lib32:/usr/lib32 and can be changed when building
binutils as it is for /tools). And it uses the dirs in /etc/ld.so.conf too.

Well, that's a mouth full.

晨想

另外一篇回复。作者：Ken Moffat。

On Fri, Sep 22, 2006 at 04:00:49AM +0800, Jonathan Davis wrote:
> > When a package is building, how does it know where to find the
> > libraries? I haven't been able to find anywhere that manages to
> > explain it very well.
> >
I shall leave that fascinating question for someone who knows the
answer!

> > To get packages to correctly located libraries do I always have to use
> > libdir=/lib64 or alter their makefiles - even if the package does not
> > compile any new libraries?

No, in a "regular" package, libdir will only control where created
libraries get installed.  But, I've seen so much weirdness recently
that there is probably a package somewhere which tries to use
--libdir to find its libraries  ;)
> >
> > Once compiled, I assume that a binary know what it needs to link to
> > based on what it was compiled with.

ldd to show what it needs.

> >  However, I want to make sure that
> > I understand how to properly deal with 64-bit libraries before I get
> > far into BCLFS so that I can avoid having problems like all of my
> > 64-bit programs attempting to link against 32-bit libraries (or vice
> > versa).  Thanks for any help that you can give me.

As a general rule, most things creating libraries probably benefit
from --libdir, but by no means all packages will respect it.  It
really helps to build on "monolib" (single size, just /lib and /usr/lib)
first, to know which packages install libraries.

On multilib, most of us make mistakes and end up putting 64-bit
libraries in /lib (or occasionally the opposite error).  Log what
gets installed (a simple find -newer works for me : doesn't get all
the headers, but it does most of the important things).  Sometimes
you will need to check what each package did before moving on.

Libtool archives (.la libraries) are sometimes a problem, mostly it
seems to be 32-bit that wants to link against 64-bit libs, try
LDFLAGS='-L/lib -L/usr/lib' on the configure, after that try
LDEMULATION (see the 32-bit libtool page in your arch's version of
multilib for the value to use).

Beyond that, many aggravations are either package-specific:

the popt in BLFS-svn is using lib64 on some platforms (x86_64, ppc64,
sparc64) regardless of which word size it is building, see the blfs
wiki

openssh often needs kicking into shape, consult the wikis (Jim told
me we have one, but I haven't looked at it yet)

kde built as 64-bit might need --with-qt-libraries=/usr/lib64
--enable-libsuffix=64 --libdir/usr/lib64 (works like that, but the
libsuffix might be auto-detected in current kde, and perhaps it
might even find qt in lib64)

a few things need config updates for x86_64 or ppc64 (mostly, use the
system's config.guess and config.sub; for jpeg search for the
configury patch for multilib

lesstif is troublesome on lib64 - I did it once, but I've resolved
not to bother again  :-)

Or else they are arch-specific:

any mozilla code probably needs ac_cv_visibility_pragma=no except on
x86.

gtk on ppc64 needs -mminimal-toc in its CFLAGS (I haven't built any
64-bit gnome code there to see if there is a knock-on effect, or
even if it works).

firefox (32-bit) doesn't work on ppc64 (that might be me, I've given
up trying to debug it, all I know is that firefox-bin returns code 1
after a couple of seconds looking about in the /usr/lib/firefox-1.5.0.x/
directory for libraries before going to ld.so.conf).  Maybe the
gecko engine will be useful for yelp and epiphany, that remains to
be seen.  Using a separate (newer) nss like the BLFS book shows for
people installing more than one mozilla product is definitely
helpful in getting any of it to build.

quite a few packages still omit -fPIC for x86_64.  I think that Mesa
on x86_64 lib64 might be straightforward, unlike x86_64-64 and ppc64
   -fPIC is also needed in libmng (sed it into the makefile.linux),
a52dec, has been needed on others in the past.  At least with this
the error message is reasonably descriptive.

I haven't touched on the use of the multilib wrapper (mainly
because my current semi-usable build predates it), but you will need
to sort out the things that come in two sizes - freetype and
fontconfig progs, gtk and pango, pkgconfig, perhaps even tiffconf.h
from libtiff (if your two wordsizes disagree about any sizeof
values - they do on ppc64).  This is why multilib is such fun!

What you _will_ need to do, if you haven't already, is decide what
you are hoping to achieve.  From that you can work out what is going
to be 32-bit, and what 64.

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

d00m3d

给个连结嘛。

晨想

我是看邮件的。不是archive。。.

题目是：
[Clfs-support] How a package locates libraries

d00m3d

我没有订阅 mailing list，通常只看 archive。。。

http://lists.linux-phreak.biz/pi ... ptember/000310.html