/usr/lib/compat and /usr/lib/compat/aout

V

vincepoy

Greetings everyone:

I was wondering what is the purpose of /usr/lib/compat and /usr/lib/compat/aout and how do I go about updating those directories as I remember in the old FreeBSD version, compat was part of the distribution, would it be safe to delete the existing content? Ofcourse, it seems compat4x/5x/6x/7x are in the ports tree which installs to /usr/local/lib/compat and /usr/local/lib/compat/aout.

Cheers,
Vince
Vincent Poy, Ph.D. - Astrophysics
 
From hier(7)

Code: 
/usr
    /lib
        /compat     shared libraries for compatibility
               /a.out       a.out backward compatibility
                                                  libraries

I have never seen anything in those directories ;) I did manage to find an ancient 3.5-STABLE somewhere, which did have files in /usr/lib/compat/aout (not a.out!), which were all from 1998!

So if you're on a recent FreeBSD, I see no point in keeping them populated (though they're likely recreated when you delete the directories).

Perhaps make delete-old or make delete-old-libs wipe them anyway. Nothing seems to fill those directories nowadays as far as I can see.
 
Those systems are from 1993 or so when FreeBSD 1.0 was initially available and in the older FreeBSD versions, I know there were the compat distribution atleast in some later versions and then compat ofcourse became part of the ports tree. You're right that world install doesn't populate those directories. Just thought about doing the manual filesystem cleanup and noticed those directories there. Anyways to update the /stand directory though as I know those are created on new installs only, though it seems 8.0-RELEASE doesn't have it, atleast from the base installation.
 
vincepoy said:
Anyways to update the /stand directory though as I know those are created on new installs only, though it seems 8.0-RELEASE doesn't have it, atleast from the base installation.
Click to expand...
/stand got removed somewhere between 5.x and 6.x.
 
Interesting, I thought the entire purpose of /stand was that those binaries are static and not dependent on the systems libraries.
 
Have a look in /rescue on a FreeBSD system since 6.x. ;)

It's a single crunchgen binary, hardlinked to all the tools you need to rescue a system in single-user mode.
 
I noticed something, it appears that for libraries that no longer exist and those that have new versions, the former and the older versions of the later can be moved to /usr/lib/compat for example since it seems like apache2 for example needs libpthread.so.1, so /usr/lib looks like this:

Code: 
lrwxr-xr-x  1 root  wheel  -      9 Feb  2 20:40 libpthread.so -> libthr.so
lrwxr-xr-x  1 root  wheel  -     13 Feb  3 15:03 libpthread.so.1 -> libpthread.so
-r--r--r--  1 root  wheel  - 141294 Feb  2 13:59 libthr.a
lrwxr-xr-x  1 root  wheel  -     16 Feb  2 20:40 libthr.so -> /lib/libthr.so.3
lrwxr-xr-x  1 root  wheel  -      9 Feb  2 20:10 libthr.so.1 -> libthr.so

as basically I created symlinks.... however, when one tries to run apache2, it goes:

Code: 
/libexec/ld-elf.so.1: /usr/lib/libpthread.so.1: version LIBTHREAD_1_0 required by /usr/local/sbin/httpd not found

so deleting /usr/lib/libpthread.so.1 and trying to see if the compat libraries in port actually works:

Code: 
lrwxr-xr-x  1 root  wheel  - 11 Feb  2 13:30 /usr/local/lib/compat/libpthread.so.1 -> libthr.so.1
lrwxr-xr-x  1 root  wheel  - 11 Feb  2 13:33 /usr/local/lib/compat/libpthread.so.2 -> libthr.so.2
-r--r--r--  1 root  wheel  - 285352 Feb  2 13:30 /usr/local/lib/compat/libthr.so.1
-r--r--r--  1 root  wheel  -  69844 Feb  2 13:33 /usr/local/lib/compat/libthr.so.2

Now attempting the starting apache2 results in:
Code: 
/libexec/ld-elf.so.1: /usr/local/lib/compat/libpthread.so.1: version LIBTHREAD_1_0 required by /usr/local/sbin/httpd not defined

Same issue as it seems that in both the compat libraries from ports and the current /usr/lib, libpthread is not a actual lib but rather points to libthr and it seems that if I copied a actual libpthread.so.1 from a November 2004 6.0-CURRENT system and place it in /usr/lib, it will start normally. I know recompiling is a option but how else would you fix the problem unless one can have the binary point to another file?
 
phoenix said:
Have a look in /rescue on a FreeBSD system since 6.x. ;)

It's a single crunchgen binary, hardlinked to all the tools you need to rescue a system in single-user mode.
Click to expand...

Thanks!

From what I observed, I think the difference between /stand and /rescue is that /rescue is built and installed when you do a build/installworld from the src tree while /stand appears to have sysinstall but /rescue doesn't.
 
It seems these are the ones not in /rescue that existed in /stand:
-sh
arp
boot_crunch (not in src tree)
cpio
etc directory consisting of defaults, netconfig, protocols, services
find
help
minigzip
ppp
slattach (doesn't exist in src tree)
sysinstall
usbd (doesn't exist in src tree)
usbdevs (doesn't exist in src tree)
 
You must log in or register to reply here.
Back
Top