Re: Why does adding /usr/lib32 to LD_LIBRARY_PATH break 64-bit binaries?
On Thu, 23 Oct 2008, Alexander Sack wrote:
Alright, well I found some weirdness:
[EMAIL PROTECTED] ~]# export
LD_LIBRARY_PATH=/usr/bin:/usr/lib:/usr/lib32:/usr/lib64
[EMAIL PROTECTED] ~]# LD_DEBUG=1 ls
/libexec/ld-elf.so.1 is initialized, base address = 0x800506000
RTLD dynamic = 0x80062ad78
RTLD pltgot = 0x0
processing main program's program header
Filling in DT_DEBUG entry
lm_init("(null)")
loading LD_PRELOAD libraries
loading needed objects
Searching for "libutil.so.5"
Trying "/usr/bin/libutil.so.5"
Trying "/usr/lib/libutil.so.5"
Trying "/usr/lib32/libutil.so.5"
loading "/usr/lib32/libutil.so.5"
/libexec/ld-elf.so.1: /usr/lib32/libutil.so.5: unsupported file layout
That's because libutil.so.5 does not exist in /usr/lib only in /lib.
The /usr/lib directory has:
[EMAIL PROTECTED] ~]# ls -l /usr/lib/libutil*
-r--r--r-- 1 root wheel 100518 Aug 21 2007 /usr/lib/libutil.a
lrwxrwxrwx 1 root wheel 17 Sep 11 11:44 /usr/lib/libutil.so ->
/lib/libutil.so.5
-r--r--r-- 1 root wheel 103846 Aug 21 2007 /usr/lib/libutil_p.a
So rtld is looking for major number 5 of libutil, without the standard
/lib in my LD_LIBRARY_PATH it searches /usr/lib, doesn't find it but:
[EMAIL PROTECTED] ~]# ls -l /usr/lib32/libutil*
-r--r--r-- 1 root wheel 65274 Aug 21 2007 /usr/lib32/libutil.a
lrwxrwxrwx 1 root wheel 12 Sep 11 11:45 /usr/lib32/libutil.so ->
libutil.so.5
-r--r--r-- 1 root wheel 46872 Aug 21 2007 /usr/lib32/libutil.so.5
-r--r--r-- 1 root wheel 66918 Aug 21 2007 /usr/lib32/libutil_p.a
And whalah, I'm broke since there is a libutil.so.5 in there.
So my question to anyone out there, WHY does /usr/lib32 contain major
numbers but /usr/lib does not? This seems like a bug to me (FreeBSD
7.0-RELEASE is the same) or at least a dubious design decision.
I think the distinction is this. rtld is looking for libutil.so.5 (with
version number). This file has to be in /lib, in the root filesystem, so
that programs can run before /usr is mounted.
libutil.so on the other hand is not searched for by rtld, but by ld
(driven by cc), when the program is built. /usr/lib is the traditional
place for it to search; I'm not sure if it searches /lib at all. In the
case of static libraries, /usr/lib is certainly the right place for
libutil.a to go, so having libutil.so there makes sense in my mind.
I think your best bet is to dig into whatever is setting LD_LIBRARY_PATH
and get it set correctly. Remove /usr/lib32 or at least ensure that /lib
is searched first. Trying to change rtld's behavior is not the right
approach, IMHO.
--
Nate Eldredge
[EMAIL PROTECTED]
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Missing cd0 device node
Hi all, In the course of various screwing around with my ATAPI CDROM device (including some dvd ripping and playing that got aborted at odd moments), I got the following messages: Sep 25 20:50:07 vulcan kernel: acd0: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly Sep 25 20:50:07 vulcan kernel: acd0: timeout waiting to issue command Sep 25 20:50:07 vulcan kernel: acd0: error issuing SETFEATURES SET TRANSFER MODE command Sep 25 20:50:07 vulcan kernel: acd0: TIMEOUT - REQUEST_SENSE retrying (1 retry left) Sep 25 20:50:18 vulcan kernel: acd0: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly Sep 25 20:50:18 vulcan kernel: acd0: timeout waiting to issue command Sep 25 20:50:18 vulcan kernel: acd0: error issuing ATA PACKET command Sep 25 20:50:18 vulcan kernel: acd0: TIMEOUT - REQUEST_SENSE retrying (0 retries left) Sep 25 20:50:29 vulcan kernel: acd0: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly Sep 25 20:50:29 vulcan kernel: acd0: timeout waiting to issue command Sep 25 20:50:29 vulcan kernel: acd0: error issuing ATA PACKET command Sep 25 20:50:29 vulcan kernel: acd0: FAILURE - REQUEST_SENSE timed out Sep 25 20:50:29 vulcan kernel: (cd0:ata0:0:0:0): lost device Sep 25 20:50:29 vulcan kernel: (cd0:ata0:0:0:0): removing device entry Sep 25 20:50:29 vulcan kernel: (probe0:ata0:0:0:0): Lost target 0??? Sep 25 20:50:45 vulcan kernel: acd0: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly Sep 25 20:50:45 vulcan kernel: acd0: timeout waiting to issue command Sep 25 20:50:45 vulcan kernel: acd0: error issuing ATA PACKET command Sep 25 20:50:45 vulcan kernel: acd0: FAILURE - TEST_UNIT_READY timed out I also have atapicam in use for DVD burning, and I now find that /dev/cd0 is missing, and I can't figure out how to get it back. "camcontrol rescan all" completes successfully, and I have vulcan# camcontrol devlist at scbus1 target 0 lun 0 () But I can't seem to do anything with the device: vulcan# camcontrol inquiry cd0 camcontrol: cam_lookup_pass: CAMGETPASSTHRU ioctl failed cam_lookup_pass: No such file or directory cam_lookup_pass: either the pass driver isn't in your kernel cam_lookup_pass: or cd0 doesn't exist vulcan# camcontrol inquiry 1:0 camcontrol: cam_open_btl: no passthrough device found at 1:0:0 All the relevant devices are in my kernel, and always have been: # ATA and ATAPI devices device ata device atadisk # ATA disk drives #device ataraid # ATA RAID drives device atapicd # ATAPI CDROM drives #device atapifd # ATAPI floppy drives #device atapist # ATAPI tape drives options ATA_STATIC_ID # Static device numbering device atapicam# emulate ATAPI devices as SCSI ditto via CAM # needs CAM to be present (scbus & pass) # SCSI Controllers # SCSI peripherals device scbus # SCSI bus (required for SCSI) #device ch # SCSI media changers device da # Direct Access (disks) #device sa # Sequential Access (tape etc) device cd # CD device pass# Passthrough device (direct SCSI access) device ses # SCSI Environmental Services (and SAF-TE) I also tried restarting /etc/rc.d/devfs and devd without effect, as well as "cdcontrol reset", and "camcontrol reset all". Any suggestions on how to recover my cd0 device so I can use it again? I suspect rebooting would fix it, but I would rather avoid rebooting this machine as it handles a number of important tasks. Thanks in advance. I'd appreciate a personal CC on any replies, if convenient, so I don't miss them in my digest. -- Nate Eldredge [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Missing cd0 device node
I forgot to mention, this is on 6.1-RELEASE-p4/amd64. Also, the /dev/acd0 node remains in existence and seems to work fine. On Tue, 26 Sep 2006, Nate Eldredge wrote: Hi all, In the course of various screwing around with my ATAPI CDROM device (including some dvd ripping and playing that got aborted at odd moments), I got the following messages: ... [see original message] I also have atapicam in use for DVD burning, and I now find that /dev/cd0 is missing, and I can't figure out how to get it back. "camcontrol rescan all" completes successfully, and I have vulcan# camcontrol devlist at scbus1 target 0 lun 0 () (see original message) -- Nate Eldredge [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Machine freezes on modem ring
Hi all, I have an odd problem with my FreeBSD box. I have an external serial modem connected, and whenever the phone rings, the system freezes momentarily. No mouse movement, etc. To diagnose it, I wrote a program that calls gettimeofday continuously, and when the phone rings there is about a 2 second interval between loops. This corresponds roughly to the time of each ring. It is certainly related to the serial modem because disconnecting the modem from the phone line fixes it. The modem works fine otherwise. There is no process listening on that port when I do this. (faxgetty from hylafax was there, but I took it out of /etc/ttys, init q, and the behavior persists.) Therefore it is either a kernel or a hardware problem. I could try booting another OS to see if that's affected as well, but I'd rather not take this box down. The machine is a single-cpu Opteron running 6.2-RELEASE/amd64. The modem is a generic external serial type and is connected to a serial port on the motherboard. There are two ports and the problem appears with the modem connected to either one. Jan 5 14:55:49 vulcan kernel: sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 Jan 5 14:55:49 vulcan kernel: sio0: type 16550A Jan 5 14:55:49 vulcan kernel: sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 Jan 5 14:55:49 vulcan kernel: sio1: type 16550A The "flags 0x10" for sio0 which was for a serial console setup appears irrelevant, since the problem arises on sio1 as well. Just curious if anyone knows what this could be. If not, I'll investigate further. Thanks in advance for any ideas. A personal CC is appreciated on replies, though I read the list as well. -- Nate Eldredge [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
