Re: Mysterious problem with ldconfig and ld

2003-01-04 Thread Justin Hopper
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

2003-01-04 Thread Mark
- 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

2003-01-03 Thread Justin Hopper
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

2003-01-03 Thread Matthew Emmerton
 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

2003-01-03 Thread Justin Hopper
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

2003-01-03 Thread Dan Nelson
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