|
Home > Archive > Unix Programming > November 2007 > error while loading shared libraries on amd64
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
error while loading shared libraries on amd64
|
|
|
| HI,
I am facing a strange problem. My application(32 bit) uses third party
32 bit shared libraries.
This run fine on Fedora Core 5 (32-bit) on intel x86.
But if I try to run the same application and libraries on Cent OS
564bit on AMD64 i68 Athlon, I get the following error
error while loading shared libraries: <mylib>.: cannot open shared
object file: No such file or directory.
I have included the libraries in /lib , updated the LD_LIBRARY_PATH
and also /etc/ld.conf , but still get the same error.
I have used the 'file' command to recheck the library and executable
to be 32-bit LSB objects and no 64 bit libraries are used.
GNU ld version is 2.17.50 on Cent OS.
Can anyone point out the reason for such an error. Please let me know
if you'll need further into.
Thanks
Yaniv
| |
| Paul Pluzhnikov 2007-11-20, 1:26 pm |
| Yaniv <yanivk10@gmail.com> writes:
> But if I try to run the same application and libraries on Cent OS
> 564bit on AMD64 i68 Athlon, I get the following error
>
> error while loading shared libraries: <mylib>.: cannot open shared
> object file: No such file or directory.
Please read this:
http://catb.org/esr/faqs/smart-questions.html
Then post the *exact* message (I very much doubt there is a
'.' character immediately preceeding the ':' in that message.
> I have included the libraries in /lib , updated the LD_LIBRARY_PATH
> and also /etc/ld.conf , but still get the same error.
You should *not* do any of the above, because /lib is already there.
> Can anyone point out the reason for such an error. Please let me know
> if you'll need further into.
The command below may provide further clues:
env LD_DEBUG=files,libs /path/to/exe
Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.
| |
|
| On Nov 20, 9:10 pm, Paul Pluzhnikov <ppluzhnikov-...@charter.net>
wrote:
> Yaniv <yaniv...@gmail.com> writes:
>
>
> Please read this:
> http://catb.org/esr/faqs/smart-questions.html
>
> Then post the *exact* message (I very much doubt there is a
> '.' character immediately preceeding the ':' in that message.
>
>
> You should *not* do any of the above, because /lib is already there.
>
>
> The command below may provide further clues:
>
> env LD_DEBUG=files,libs /path/to/exe
>
Thanks a lot Paul, your suggestion helped.
As mentioned in my post the there was a 'dot' following the library
name . It was actually a softlink to the actual library
"libapi_v2_Core.so" When I ran env LD_DEBUG=files,libs /path/to/exe it
clearly showed it
was searching for "libapi_v2_Core.so." and *not* "libapi_v2_Core.so "
which I missed completely.
I created the softlink libapi_v2_Core.so. and it worked fine.
Yaniv
| |
| Paul Pluzhnikov 2007-11-21, 1:25 pm |
| Yaniv <yanivk10@gmail.com> writes:
> As mentioned in my post the there was a 'dot' following the library
> name.
That's certainly unconventional.
> It was actually a softlink to the actual library
> "libapi_v2_Core.so" When I ran env LD_DEBUG=files,libs /path/to/exe it
> clearly showed it was searching for "libapi_v2_Core.so." and *not* "libapi_v2_Core.so "
> which I missed completely.
This probably means that the owner of that library intended to do
-Wl,-soname,libapi_v2_Core.so.$MAJOR
but neglected to set $MAJOR correctly. If you are the owner, you
should read about external library versioning, e.g. here:
http://docs.sun.com/app/docs/doc/81...mhm7pl20?a=view
If you are not the owner, you should probably tell the owner there
is a likely bug in his makefile.
Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.
|
|
|
|
|