I have a makefile in Mac OS X and the last command line for the final compilation is:
gcc count_words.o lexer.o -lfl -o count_words
but it responds:
ld: library not found for -lfl
collect2: ld returned 1 exit status
I found that the library libfl.a is in /opt/local/lib/ and that modifying the command line to read:
gcc count_words.o lexer.o -L/opt/local/lib/ -lfl -o count_words
it works perfectly, but I've read when a prerequisite of the form -l is seen, GNU make searches for a file of the form libNAME.so; if no match is found, it then searches for libNAME.a. Here make should find /opt/local/lib/libfl.a and proceed with the final action, linking, but this is not happening.
I tried using LD_LIBRARY_PATH, then realized that as I'm working on Mac I have to use DYLD_LIBRARY_PATH, I exported the variable pointing to /opt/local/lib and tried running the makefile again, didn't work. Found another environment variable called DYLD_FALLBACK_LIBRARY_PATH, exported, didn't work.
What should I do?
DYLD_LIBRARY_PATH (and LD_LIBRARY_PATH on other unices) provides search paths for the loader, to resolve linked libraries at runtime. LIBRARY_PATH is the relevant var for providing paths that the compiler will pass to the linker at link time.
However, OS X's linker ld64 has no way to prefer static linking over dynamic in the presence of both kinds of libraries, which means your only option is to pass the full path to the archive anyway.
gcc count_words.o lexer.o /opt/local/lib/libfl.a -o count_words
Which is really all that -l does after it searches the paths and expands the lib name.
make does not search for the library at all. make just invokes other tools that do that. (ld, which is invoked by gcc) All you need to do is pass the proper flags to gcc from make. Possibly, this just means adding
LDFLAGS=-L/opt/local/lib
to your Makefile (or editing the command directly, as it appears you have done during testing), but it is difficult to tell without seeing the Makefile.
Probably this question Library not found for -lfl is relevant. For some reason if you try -ll instead of -lfl it works on OS X. Also see http://linux-digest.blogspot.hk/2013/01/using-flex-on-os-x.html
Related
I'm trying to use pcap functions, but it giving me compiler error:
project.c:(.text+0x140): undefined reference to `pcap_open_offline'
I have installed library and while compiling I give "-lpcap" at the and as it advised in many forums.
What can be wrong, please?
You need to understand what the arguments evoke into the linker.
I am supposing you are using Linux system with gcc, using ld as linker (note that this could change depending on the system and the linker used).
In such case, -Lpath tell the linker where to look for the libraries that you tell it that are needed to be linked with your program to create the final binary. For example -L/usr/lib.
when you type in for example:
# gcc -L/usr/lib -lcap my_program.c -o my_program
You are telling the linker to append /usr/lib to the list of paths to locate libraries, and to link the dynamic library "libcap.so" with your program.
Other modifiers for the path used to locate libraries is LD_LIBRAY_PATH (the name of this environment variable could change from one system to another, review the manual of your linker).
As you are using "-lcap" the error you get look to be related with the fact that no path is found where libcap.so exist. Locate that file into your system and pass the argument
-L/path/to/the/directory/that/contain/libcap.so
By the way, try to run this before any other thing and recompile:
# sudo ldconfig
I am trying to use sqlite3 in my Eclipse C project, I have added sqlite3.h and its address: /usr/include/ to linker, but still get this error message:
make all
Building target: SQLiteTest
Invoking: GCC C Linker
gcc -L/usr/include/ -o "SQLiteTest" ./hello.o -lsqlite3.h
/usr/bin/ld: cannot find -lsqlite3.h
collect2: error: ld returned 1 exit status
make: *** [SQLiteTest] Error 1
I guess I have to add it to compiler as well, have tried many ways, but none of them worked.
Thanks for help
When compiling and linking C programs:
the -I/some/where/include option is used to specify where headers (include files) are found,
the -L/some/where/lib option is used to specify where libraries are found,
the -lname option is used to say "link with the library libname.so or libname.a"
The suffixes on libraries vary by platform — choose from .sl, .sa, .dll, .lib, .dylib, .bundle, to name but a few alternative extensions.
The -L/usr/include option is unlikely to be correct. Headers are stored in /usr/include, and not libraries. Changing that to -I/usr/include is unnecessary; the compiler will search in /usr/include anyway. If the sqlite3.h header is in /usr/include, it will be found without options. If it is somewhere else, like perhaps /usr/local/include or /opt/sqlite3/include, then you may well need to specify -I/usr/local/include or -I/opt/sqlite3/include on the command line. In each case, you might also need -L/usr/local/lib or -L/opt/sqlite3/lib as well. (Note that your compiler might, but probably won't, search in /usr/local automatically.)
As noted in the comments, you would not specify -lsqlite3.h on the command line. It would mean that there was a library such as libsqlite3.h.so somewhere on your system, which is an implausible name. Most likely, you should just specify -lsqlite3 on the linking command line.
I don't get it. I usually install third party software into /usr/local so libraries are installed into /usr/local/lib and never had problems linking to these libraries. But now it suddenly no longer works:
$ gcc -lkaytils -o test test.c
/usr/bin/ld.gold.real: error: cannot find -lkaytils
/usr/bin/ld.gold.real: /tmp/ccXwCkYk.o: in function main:test.c(.text+0x15):
error: undefined reference to 'strCreate'
collect2: ld returned 1 exit status
When I add the parameter -L/usr/local/lib than it works but I never had to use this before. Header files in /usr/local/include are found without adding -I/usr/local/include.
I'm using Debian GNU/Linux 6 (Squeeze) which has an entry for /usr/local/lib in /etc/ld.so.conf.d/libc.conf by default and the ldconfig cache knows the library I'm trying to use:
k#vincent:~$ ldconfig -p | grep kaytils
libkaytils.so.0 (libc6,x86-64) => /usr/local/lib/libkaytils.so.0
libkaytils.so (libc6,x86-64) => /usr/local/lib/libkaytils.so
So what the heck is going on here? Where can I check which library paths are searched by gcc by default? Maybe something is wrong there.
gcc -print-search-dirs will tell you what path the compiler checks. /usr/local/lib is simply not among them, so your compile time linker (in this case the new gold ld from binutils) doesn't find the library while the dynamic one (ld-linux.so which reads the cache written by ldconfig) does. Presumably the builds you've done previously added -L/usr/local/lib as necessary in their makefiles (usually done by a ./configure script), or you installed binaries.
This is probably an issue of environment variables - you have something set that's including /usr/local/include but not /usr/local/lib
From the GCC mapage on environment variables
CPATH specifies a list of directories to be searched as if speci‐
fied with -I, but after any paths given with -I options on the com‐
mand line. This environment variable is used regardless of which
language is being preprocessed.
and
The value of LIBRARY_PATH is a colon-separated list of directories,
much like PATH. When configured as a native compiler, GCC tries
the directories thus specified when searching for special linker
files, if it can’t find them using GCC_EXEC_PREFIX. Linking using
GCC also uses these directories when searching for ordinary
libraries for the -l option (but directories specified with -L come
first).
try "printenv" to see what you have set
I am trying to compile a c program using LLVM and I am having trouble getting some static libraries included. I have successfully compiled those static libraries using LLVM and, for example, libogg.a is present, as is ogg.l.bc.
However, when I try to build the final program, it does not include the static ogg library. I've tried various compiler options with the most notable being:
gcc oggvorbis.c -O3 -Wall -I$OV_DIR/include -l$OV_DIR/lib/libogg.a -l$OV_DIR/lib/libvorbis.a -o test.exe
This results in the following output (directories shortened for brevity):
$OV_DIR/include/vorbis/vorbisfile.h:75: warning: ‘OV_CALLBACKS_DEFAULT’ defined but not used
$OV_DIR/include/vorbis/vorbisfile.h:82: warning: ‘OV_CALLBACKS_NOCLOSE’ defined but not used
$OV_DIR/include/vorbis/vorbisfile.h:89: warning: ‘OV_CALLBACKS_STREAMONLY’ defined but not used
$OV_DIR/include/vorbis/vorbisfile.h:96: warning: ‘OV_CALLBACKS_STREAMONLY_NOCLOSE’ defined but not used
llvm-ld: warning: Cannot find library '$OV_DIR/lib/ogg.l.bc'
llvm-ld: warning: Cannot find library '$OV_DIR/lib/vorbis.l.bc'
WARNING: While resolving call to function 'main' arguments were dropped!
I find this perplexing because $OV_DIR/lib/ogg.l.bc DOES exist, as does vorbis.l.bc and they are both readable (as are their containing directories) by everyone.
Does anyone have any idea with what I am doing wrong?
Thanks,
Matt
As unwind said,
-l is followed by the library name.
For example, in linux library naming conventions,
if a library is named libogg,
-logg will find and choose the *best match in the library directories.
You can add a directory into the list:
-L option is one of the way to add the following folder to the list temporarily.
The environment variable LD_LIBRARY_PATH also affects the list on most of Linux/Unix > with GNU tools.
gcc may find both static and shared library files whose name matches with the requested library name.
For example,
libogg.a
libogg.so
That's why there is a gcc option, -static
-static
On systems that support dynamic linking, this prevents linking
with the shared libraries. On other
systems, this option has no effect.
If you just want to use a shared or static library file - directly, just as an object file,
then give their path without any option, like
gcc oggvorbis.c the_path/libogg.a
I don't think the -l option expects paths. You should split those out, and use the -L option to set the paths, then just use plain library names with -l:
$ gcc oggvorbis.c -O3 -Wall -I$OV_DIR/include -L$OV_DIR/lib -logg -lvorbis -o test.exe
Also note that when used like this, you don't include the "lib" and ".a" parts of the library name.
I am creating a utility which depends on libassuan aside other depends. While these ‘others’ provide shared libraries, libassuan comes with static one only.
libassuan comes with simple libassuan-config tool which is meant to provide CFLAGS & LDFLAGS for the compiler/linker to use. These LDFLAGS refer to the library as -lassuan.
The result of standard call of make is then:
cc -I/usr/include/libmirage -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -lmirage -lglib-2.0 -L/usr/lib64 -lassuan -o mirage2iso mirage2iso.c mirage-getopt.o mirage-wrapper.o mirage-password.o
mirage-password.o: In function `mirage_input_password':
mirage-password.c:(.text+0x1f): undefined reference to `assuan_pipe_connect'
mirage-password.c:(.text+0x32): undefined reference to `assuan_strerror'
collect2: ld returned 1 exit status
make: *** [mirage2iso] Error 1
(I've just started writing this unit and that's why there aren't more errors)
So, if I understand the result correctly, gcc doesn't want to link the app to libassuan.a.
Using -static here will cause gcc to prefer static libraries over shared which is unindented. I've seen solution suggesting using something like that:
-Wl,-Bstatic -lassuan -Wl,-Bdynamic
but I don't think it would be a portable one.
I think the best solution would be to provide full path to the static library file but libassuan-config doesn't provide much of help (all I can get from it is -L/usr/lib64 -lassuan).
Maybe I should just try to create the static library path by ‘parsing’ returned LDFLAGS and using -L for the directory name and -l for the library name — and then hoping that in all cases libassuan-config will return it like that.
What do you think about that? Is there any good, simple and portable solution to resolve the issue?
PS. Please note that although I'm referring to gcc here, I would like to use something that will work fine with other compilers.
PS2. One additional question: if package does install static library only, returning such LDFLAGS instead of full .la path can be considered as a bug?
gcc will link to libassuan.a if it doesn't find libassuan.so
It's probably the order symbols are looked up in the static library when you link. The order matters.
)
Assuming gcc can find libassuan.a and it actually provides the functions the linker complains about, try:
cc -I/usr/include/libmirage -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -lmirage -lglib-2.0 -L/usr/lib64 -o mirage2iso mirage2iso.c mirage-getopt.o mirage-wrapper.o mirage-password.o -lassuan
Since you say libassuan is under /usr/lib64 it's probably a 64 bit library, are your app and the other libraries 64 bit as well ?
Compiler's command-line options are not a portable thing. There's no standard for it. Every compiler uses its own and several can merely informally agree to comply with each other in command-line format. The most portable way for your linking is to use libassuan-config, of course. I think, it can generate not only flags for gcc, but for other compilers as well. If it can't, then no portable way exists, I suppose (other than CMake or something on higher level).
The command line to cc you shown is totally correct. If you have a static library libassuan.la and path to it is supplied to -L option, then the compiler does link against it. You can see it from its output: has it not found the static library, would it complain with error message like "can't find -lassuan". I
Moreover, if no libassuan.so is found, then compiler links against your library statically, even if you haven't used -Wl,-Bstatic stuff or -static flag.
Your problem may be in persistence of several versions of libassuan in your system. Other that that, I don't see any errors in what you've provided.
Which directory is libassuan.a in
I think the first error is not gcc doesn't want to link the app to libassuan.a it is more gcc does not know where libassuan.a . You need to pass gcc a -L parameter giving the path to libassuan.a .
e.g.
-L /home/path