Re^3: libiconv wont work :(

the second outputs:

[pid 20181] open("/lib64/tls/x86_64/libiconv.so.2", O_RDONLY) = -1 ENO
+ENT (No such file or directory)
[pid 20181] open("/lib64/tls/libiconv.so.2", O_RDONLY) = -1 ENOENT (No
+ such file or directory)
[pid 20181] open("/lib64/x86_64/libiconv.so.2", O_RDONLY) = -1 ENOENT 
+(No such file or directory)
[pid 20181] open("/lib64/libiconv.so.2", O_RDONLY) = -1 ENOENT (No suc
+h file or directory)
[pid 20181] open("/usr/lib64/tls/x86_64/libiconv.so.2", O_RDONLY) = -1
+ ENOENT (No such file or directory)
[pid 20181] open("/usr/lib64/tls/libiconv.so.2", O_RDONLY) = -1 ENOENT
+ (No such file or directory)
[pid 20181] open("/usr/lib64/x86_64/libiconv.so.2", O_RDONLY) = -1 ENO
+ENT (No such file or directory)
[pid 20181] open("/usr/lib64/libiconv.so.2", O_RDONLY) = -1 ENOENT (No
+ such file or directory)
    libiconv.so.2 => not found
[download]

Comment on Re^3: libiconv wont work :( Download Code

Replies are listed 'Best First'.
Re^4: libiconv wont work :( by Anonymous Monk on Dec 06, 2010 at 18:19 UTC
This looks like a 64- vs. 32-bit lib directory problem. There are generally two types of mixed 64/32-bit Linux distros: one type puts the 'native' 64-bit libs in `/usr/lib` etc., and the old 32-bit libs in some 'compat' directory, typically `/usr/lib32`. The other puts the 64-bit libs in `/usr/lib64` etc., and leaves the old 32-bit libs in `/usr/lib`. Everything else in the system is compiled and set up such that the appropriate lib directories are being searched by 64- and 32-bit binaries respectively. Both approaches have their pros and cons, which is why you find them both... Your system looks like the second type. In other words, if your self-built `libiconv.so.2` is in fact 64-bit (as it seems to be, otherwise using LD_LIBRARY_PATH wouldn't have helped), it should actually live in a directory with '64' in its name (e.g. `/usr/lib64`). PS: you can check 64/32-bitness with `file -L /usr/lib/libiconv.so.2`	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^4: libiconv wont work :(
by Anonymous Monk on Dec 06, 2010 at 18:19 UTC

There are generally two types of mixed 64/32-bit Linux distros: one type puts the 'native' 64-bit libs in /usr/lib etc., and the old 32-bit libs in some 'compat' directory, typically /usr/lib32. The other puts the 64-bit libs in /usr/lib64 etc., and leaves the old 32-bit libs in /usr/lib. Everything else in the system is compiled and set up such that the appropriate lib directories are being searched by 64- and 32-bit binaries respectively. Both approaches have their pros and cons, which is why you find them both...

Your system looks like the second type. In other words, if your self-built libiconv.so.2 is in fact 64-bit (as it seems to be, otherwise using LD_LIBRARY_PATH wouldn't have helped), it should actually live in a directory with '64' in its name (e.g. /usr/lib64).

PS: you can check 64/32-bitness with file -L /usr/lib/libiconv.so.2

[reply]
[d/l]
[select]