Re^2: libiconv wont work :(

Replies are listed 'Best First'.
Re^3: libiconv wont work :( by Sinistral (Monsignor) on Dec 06, 2010 at 17:35 UTC
You have a couple of options. One would be to uninstall your CPAN module, make sure you use your distribution's package manage to install libiconv, then rebuild the CPAN modules so that they will use the OS paths for the libraries. If you want to use the libiconv that you built yourself, then what you can do (you have to be root to do this) is to add /usr/local/lib to your /etc/ld.so.conf. If you have a Red Hat or Red Hat like system (CentOS, Fedora) then you can simply add a new file in /etc/ld.so.conf.d named anything you want (but in this case usrlocal.conf would be good)with the contents: `/usr/local/lib` [download] Since you want this to work for your web server and Perls spawned by it (I'm guessing Apache), then what you can do is in your httpd.conf specify the environment variable to be passed on using this syntax: `SetEnv LD_LIBRARY_PATH /usr/lib:/usr/local/lib` [download] I only list /usr/lib and /usr/local/lib, but you'll want every path to be included in there, because setting LD_LIBRARY_PATH overrides the complete value used by all programs spawned by the web server (not just Perl). Not specifying everything could lead to Big Problems for CGI executables.	[reply] [d/l] [select]
Re^3: libiconv wont work :( by Corion (Patriarch) on Dec 06, 2010 at 17:22 UTC
Most likely, changing `%ENV` is only respected when launching new processes by your OS, and does not affect a currently running process. Either launch your process through a shell script wrapper that sets up the environment, or restart your Perl program by using (something like) `exec $0 => @ARGV`. The second approach might fail when `$0` does not resolve to a valid filename.	[reply] [d/l] [select]
Re^4: libiconv wont work :( by kosta (Sexton) on Dec 06, 2010 at 17:23 UTC
wait does my output mean that I just need to link it to /usr/lib64/libiconv.so.2 That would be awesome!	[reply]
Re^3: libiconv wont work :( by kosta (Sexton) on Dec 06, 2010 at 17:21 UTC
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]	[reply] [d/l]
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]