Of course, I still haven't gotten around to making the libacl.so yet. Busy on
a few other fronts right now. But... poking around on my Linux box reveals:
[jt@jtsdell jt]$ cd /lib
[jt@jtsdell /lib]$ ls *.a
libacl.a liblvm.a libpam_misc.a libpwdb.a
On a solaris box:
bash-2.02$ pwd
/lib
bash-2.02$ ls *.a
lib300.a libbsm.a libgenIO.a libnisdb.a libsocket.a
lib300s.a libc.a libintl.a libnls.a libvolmgt.a
lib4014.a libc2.a libkrb.a libnsl.a libvt0.a
lib450.a libc2stubs.a libldfeature.a libpkg.a libw.a
libTL.a libcmd.a libm.a libplot.a null.a
libadm.a libcrypt.a libmail.a librac.a
libauth.a libcrypt_i.a libmapmalloc.a librpcsvc.a
libbsdmalloc.a libelf.a libmp.a libsec.a
So the placement of *.a libs in /lib is not unheard of.
On 21-Jul-2001 Juergen Hasch wrote:
> Hello Seth,
>
> Am Samstag, 21. Juli 2001 22:36 schrieb Seth Mos:
>> At 22:12 21-7-2001 +0200, Juergen Hasch wrote:
>> >Am Freitag, 20. Juli 2001 10:26 schrieb Nathan Scott:
>> > > Important change for xfsdump and xfsrestore (and libraries that they
>> > > rely on)... we're now consistent with other backup/restore utilities
>> > > which need be available when only the root filesystem is mounted.
>> >
>> >What is the reason for putting libacl.a in /lib instead of leaving it in
>> >/usr/lib where it belongs IMHO ?
>> >This breaks all applications that try to link libacl.a at compiletime like
>> >Samba and Fileutils. Please move it back.
>>
>> NO!
>>
>> If you only have your root filesystem, how would you then be able to run
>> xfsdump or xfsrestore.
>> let's see.
>>
>> You have a seriuous crash of your system and the /usr filesystem is lost.
>> This means that you need to restore the /usr filesystem.
>> Now comes the fun part, you run xfsrestore to get your /usr filesystem back
>> but onfortunately you can't run xfs_repair to repair the fs or run
>> xfsrestore to restore your backup.
>
> libacl.a is a static library that is used only at compile time. This is
> because libacl.a contains only the stubs for libacl.so.
> No-one has *.a files in /lib, they are all in /usr/lib. Take a look in your
> /lib directory. You find the stubs for e.g. libc as /usr/lib/libc.a, but
> the actual libc.so in /lib.
> So you need libacl.so in /lib and libacl.a in /usr/lib.
>
> ...Juergen
--
John M. Trostel
Linux OS Engineer
Connex
jtrostel@xxxxxxxxxx
|