Re: Mysterious problem with ldconfig and ld
When running ldconfig, it saves the information in the /var/run/ld-elf.so.hints file, and I assume that ld should then know where libraries are located, since they are in this cache file. So when running: ld -lexpat, why did ld not know the location of the expat library, when it is in the cache (hints) file? -- Justin Hopper [EMAIL PROTECTED] UNIX Systems Engineer http://www.spry.com ---BeginMessage--- In the last episode (Jan 03), Justin Hopper said: Hmmm, I guess I just assumed that since ldconfig had cached the absolute path to the library, ld would not need to know the library path as well, but for some reason it did. What ultimately fixed the problem was hardcoding the -L /usr/local/lib in the configure script, since it refused to pick up that directory any other way. Thanks for your help. As a point of curiosity, I'd still like to know why ld would still need the -L /usr/local/lib if the full path to the library is already in the cache? what cache? ld and the run-time linker are separate entities and share no inrofmation. -- Dan Nelson [EMAIL PROTECTED] ---End Message---
Re: Mysterious problem with ldconfig and ld
- Original Message - From: Justin Hopper [EMAIL PROTECTED] To: Matthew Emmerton [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Saturday, January 04, 2003 5:35 AM Subject: Re: Mysterious problem with ldconfig and ld What ultimately fixed the problem was hardcoding the -L /usr/local/lib in the configure script, since it refused to pick up that directory any other way. Thanks for your help. As a point of curiosity, I'd still like to know why ld would still need the -L /usr/local/lib if the full path to the library is already in the cache? If you ever do find out, be sure to let us know. I had a similar problem once, be it with a MySQL library, and ultimately I had to resort to putting a symbolic link in /usr/lib to the /usr/local/lib library. That worked too, be it not a real elegant solution. - Mark To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Mysterious problem with ldconfig and ld
This may be a very simple fix, but so far I've found no solution. Just installed expat-1.95.5 in a FreeBSD 4.4 machine. The install went fine, and I verified that ldconfig had picked up the library: host# ldconfig -r | grep expat 73:-lexpat.4 = /usr/local/lib/libexpat.so.4 However, I need to install other packages that require the expat library, and the configuration fails stating that the expat library cannot be found. In fact, just a simple test fails: host# ld -lexpat /usr/libexec/elf/ld: cannot find -lexpat I made sure any previous installations of expat were nuked and all files deleted. And the /usr/local/lib/libexpat.so.4 does exist: higherinnovation# ll /usr/local/lib/libexpat.so.4 -rwxr-xr-x 1 root wheel 294728 Jan 3 19:44 /usr/local/lib/libexpat.so.4 If ldconfig has an entry for the library and is pointing correctly, what is the problem? Maybe I've just been staring at this for too long. Any help would be appreciated. -- Justin Hopper [EMAIL PROTECTED] UNIX Systems Engineer http://www.spry.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: Mysterious problem with ldconfig and ld
This may be a very simple fix, but so far I've found no solution. Just installed expat-1.95.5 in a FreeBSD 4.4 machine. The install went fine, and I verified that ldconfig had picked up the library: host# ldconfig -r | grep expat 73:-lexpat.4 = /usr/local/lib/libexpat.so.4 However, I need to install other packages that require the expat library, and the configuration fails stating that the expat library cannot be found. In fact, just a simple test fails: host# ld -lexpat /usr/libexec/elf/ld: cannot find -lexpat How about ld -L/usr/local/lib -lexpat? Works fine here: gabby# ld -L /usr/local/lib -lexpat /usr/libexec/elf/ld: warning: cannot find entry symbol _start; not setting start address /usr/local/lib/libexpat.so: undefined reference to `memmove' /usr/local/lib/libexpat.so: undefined reference to `memcpy' /usr/local/lib/libexpat.so: undefined reference to `malloc' /usr/local/lib/libexpat.so: undefined reference to `realloc' /usr/local/lib/libexpat.so: undefined reference to `memset' /usr/local/lib/libexpat.so: undefined reference to `free' gabby# If some programs can't find it, it's probably because /usr/local/lib isn't in their search path. -- Matt Emmerton To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: Mysterious problem with ldconfig and ld
Hmmm, I guess I just assumed that since ldconfig had cached the absolute path to the library, ld would not need to know the library path as well, but for some reason it did. What ultimately fixed the problem was hardcoding the -L /usr/local/lib in the configure script, since it refused to pick up that directory any other way. Thanks for your help. As a point of curiosity, I'd still like to know why ld would still need the -L /usr/local/lib if the full path to the library is already in the cache? -- Justin Hopper [EMAIL PROTECTED] UNIX Systems Engineer http://www.spry.com ---BeginMessage--- This may be a very simple fix, but so far I've found no solution. Just installed expat-1.95.5 in a FreeBSD 4.4 machine. The install went fine, and I verified that ldconfig had picked up the library: host# ldconfig -r | grep expat 73:-lexpat.4 = /usr/local/lib/libexpat.so.4 However, I need to install other packages that require the expat library, and the configuration fails stating that the expat library cannot be found. In fact, just a simple test fails: host# ld -lexpat /usr/libexec/elf/ld: cannot find -lexpat How about ld -L/usr/local/lib -lexpat? Works fine here: gabby# ld -L /usr/local/lib -lexpat /usr/libexec/elf/ld: warning: cannot find entry symbol _start; not setting start address /usr/local/lib/libexpat.so: undefined reference to `memmove' /usr/local/lib/libexpat.so: undefined reference to `memcpy' /usr/local/lib/libexpat.so: undefined reference to `malloc' /usr/local/lib/libexpat.so: undefined reference to `realloc' /usr/local/lib/libexpat.so: undefined reference to `memset' /usr/local/lib/libexpat.so: undefined reference to `free' gabby# If some programs can't find it, it's probably because /usr/local/lib isn't in their search path. -- Matt Emmerton ---End Message---
Re: Mysterious problem with ldconfig and ld
In the last episode (Jan 03), Justin Hopper said: Hmmm, I guess I just assumed that since ldconfig had cached the absolute path to the library, ld would not need to know the library path as well, but for some reason it did. What ultimately fixed the problem was hardcoding the -L /usr/local/lib in the configure script, since it refused to pick up that directory any other way. Thanks for your help. As a point of curiosity, I'd still like to know why ld would still need the -L /usr/local/lib if the full path to the library is already in the cache? what cache? ld and the run-time linker are separate entities and share no inrofmation. -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message