2

I compiled a few libraries using Eclipse-CDT on windows. However, when I tried to compile them under linux gcc keeps giving me the error /usr/bin/ld: cannot find -lrequestedLib. I'm using the exact same build settings between the two environments (namely I made sure to add the directories that contain the libraries i need to link to). I'm sure the system has read access rights to the files as well. I'm not sure what to make of this. Please help.

Edit: These are the commands that ecplise runs to build the library:

gcc -I/home/me/lib/ -O3 -Wall -c -fmessage-length=0 -olibToMake.o ../libToMake.c 
gcc -L/home/me/lib/ -shared -olibToMake.so libToMake.o -lrequestedLib

Edit 2: The command that renders the error is the second of the two, resulting in the /usr/bin/ld: cannot find -lrequestedLib being output.

Edit 3: I've confirmed that requestedLib.so is a x86_64 binary.

Caleb Waggoner
  • 147
  • 1
  • 2
  • 13

2 Answers2

0

If you don't want to pass -L command line options to gcc(1), be sure to add the path containing the libraries to /etc/ld.so.conf or /etc/ld.so.cond.d/<something>.

Once you've installed your libraries you also need to run ldconfig(8) by hand. (Most new users forget this step because typical package managers take care of this for you when installing new libraries.)

sarnold
  • 102,305
  • 22
  • 181
  • 238
  • I am passing the -L command to gcc though... "gcc -I/home/me/lib/ -O3 -Wall -c -fmessage-length=0 -olibToMake.o ../libToMake.c" "gcc -L/home/me/lib/ -shared -olibToMake.so libToMake.o -lrequestedLib" are the commands I run, but the output is as it said. I'll try running the config though, jik – Caleb Waggoner Nov 18 '11 at 00:21
  • Nope, didn't help at all. >_>; – Caleb Waggoner Nov 18 '11 at 00:27
  • Hrm; can you [edit] your question and copy-paste those commands directly into it? They might be the key that helps someone solve the problem. – sarnold Nov 18 '11 at 00:28
0

gcc -I/home/me/lib/ -O3 -Wall -c -fmessage-length=0 -olibToMake.o ../libToMake.c
gcc -L/home/me/lib/ -shared -olibToMake.so libToMake.o -lrequestedLib

When building 64-bit shared libraries on x86_64, the -fPIC flag is usually required, or you get a recompile with -fPIC error at shared library link time.

Since you didn't use -fPIC, yet your link succeeded, you are likely using (non-default) gcc that targets i*86 (that is, produces 32-bit output). You can confirm that by running file libToMake.so.

You didn't show that command that actually fails (the one that produces cannot find -lrequestedLib error). I am guessing that that command is using a different gcc (default one?), that targets x86_64. If it looks something like

gcc main.c -L/home/me/lib -lrequestedLib

that command will ignore /home/me/lib/librequestedLib.so (because you can't link together 32-bit and 64-bit code), and will continue searching for librequestedLib elsewhere. When it can't find a 64-bit version of librequestedLib, it will produce the error message you are gettiing.

Employed Russian
  • 199,314
  • 34
  • 295
  • 362
  • Tried adding *what*??? I didn't suggest that you add anything, only that you understand the problem. I am guessing you added `-fPIC`. Of *course* that wouldn't work. But *if* my guess is correct, adding `-m32` to the compile and link command for the final binary *will* work. – Employed Russian Nov 19 '11 at 22:15
  • @CalebWaggoner Please don't cut/paste your errors into comments. Update your question instead. You *still* have not answered the most basic question: whether your `librequestedLib.so` (the one you successfully built) is a 32-bit or a 64-bit one. The fact that you keep naming it differently: `memMan.so`, `librequestedLib.so`, `libToMake.so` doesn't help either. You are just adding more confusion to the already confusing picture. – Employed Russian Nov 22 '11 at 05:34
  • About your first assumption, the library compiles to x86_64. To your second assumption, there's only one binary gcc on my system and that obviously will not even attempt to compile something into i*86 architecture. To your third assumption, the two commands that are shown are the only that run. gcc runs ld in the background to find prereq libraries for linking. The reason I tried what was mentioned is that it might have helped. But what I need to know, and cannot seem to divine is why gcc (or ld?) will not look in the specified directory for the library when it was told to. – Caleb Waggoner Nov 23 '11 at 02:42
  • @CalebWaggoner Ok, it's obvious I over-thought the problem. The problem appears trivial: there is no `librequestedLib.so` in `/home/me/lib`. What does `ls -l /home/me/lib/librequestedLib*` say? – Employed Russian Nov 23 '11 at 02:53
  • So I added "lib" as a prefix and that seems to have fixed that linking issue. Is there a way to make it so that it will look for the lib without the prefix? Also this lib is asking for an entry point, even though its supposed to be a shared library (it's off topic but), any thoughts? – Caleb Waggoner Nov 23 '11 at 04:43