0

I downloaded iconv yesterday, and installed it using:

$ ./configure --prefix=/usr/local
$ make
$ make install

When I tried to run iconv from the shell, I got a complaint that the shared object file is not found, so I executed export LD_LIBRARY_PATH=/usr/local/lib. Then iconv worked.

This caused an error in my application. I was unaware that one of the source files already included iconv.h. Today I successfully built the debug version multiple times in eclipse, but when it comes to the release build, I get these errors:

undefined reference to `libiconv_close' 
undefined reference to `libiconv_open'  
undefined reference to `libiconv'

I then panicked, and ran make uninstall, restarted, but the problem remains. How can I get my program working again?

ldconfig -v | grep "iconv" shows:
libiconv.so.2 -> libiconv.so.2.5.1

I'm on Ubuntu 12.04 LTS

Innkeeper
  • 663
  • 1
  • 10
  • 22

1 Answers1

1

LD_LIBRARY_PATH is an override that should be used only for debugging purpose, or to work around bugs that would be too hard to fix otherwise.

In no case should you set it globally in your environment, because exactly what you described here is bound to happen sooner or later, especially when you're installing manually compiled software to system directories... (Question: Why didn't you install iconv via your package manager? That should always be your first choice.)

If your iconv installation requires a library path, create an alias with a local override:

alias iconv="LD_LIBRARY_PATH=/usr/local/lib iconv"

This makes iconv run correctly, but does not influence other packages, or build processes.

Bottom line, find the export LD_LIBRARY_PATH=... (wherever you might have put it), and get rid of it. That should make your application compile correctly again (unless, of course, you have borked your system by manual installs / uninstalls to /usr...)

DevSolar
  • 67,862
  • 21
  • 134
  • 209
  • Thank you, I've learned my lesson. I can run my program again, after I've added `-liconv`, and copied the shared object file in `/usr/lib`. How come it ran without this previously? `iconv.h` is not copied in the project. – Innkeeper Aug 29 '14 at 11:44
  • @Innkeeper: It's hard to tell, as you didn't give enough information. (Not that I'm too interested in finding out.) General rule, **never** manually poke around in **/usr**. You can `--prefix` software to somewhere in ${HOME} if necessary, but `/usr` should be the sole domain of your package manager. You are **bound** to get into troubles later (e.g. when the package manager removes, or overwrites, the files you put into `/usr` manually). – DevSolar Aug 29 '14 at 11:48
  • Ok, after seeing your edit, it's clear that the copying was also not the right way. The problem is I'm not sure exactly what would the correct procedure be after running `make install`. Because it did not work with just that. – Innkeeper Aug 29 '14 at 11:48
  • @Innkeeper: Repeat, any manual compilation should be `--prefix`'ed to some **non**-system directory, and that **only** if the software in question is not available via your distribution's package manager. I am 100% certain `iconv` **is** available via `apt-get`. – DevSolar Aug 29 '14 at 11:50
  • @Innkeeper: No problem. I *do* recommend a reinstall of your system, though, because things like this tend to screw up your system and result in *very* hard to track problems later on. ;-) – DevSolar Aug 29 '14 at 12:00