I'm trying to compile a program using clang with this command:
clang test.c -otest -L/var/sdk/usr/lib/
However, ld seems to ignore this completely and instead searches for library in the default directory, leaving this error:
ld: file not found: /usr/lib/system/libcache.dylib for architecture armv7
Did I do something wrong? How can I fix this?
Ok, so I have found the solution to my own question:
It was weird, somehow clang just doesn't like -L , but when I tried to using -isysroot/var/sdk/ , clang finally decided to find the libraries (and headers) in the directory that I specified.
Hope this will help others with the same problem.
Related
I'm using OSX command line gcc and attempting to build a dynamic library. when I do the build I get the following warning. How is it it is not finding this library given /usr/lib is well known? And /usr/lib does indeed exist on my machine
this is what I am using:
gcc -arch i386 cata/*.c -dynamiclib -o build/cata.dylib -LC_ID_DYLIB=/usr/lib
Thanks
the way i solved it was to make it so the string that got stuck in the library (on where to find the library at runtime) was relative to nowhere -- if that makes sense. so it would be forced to use the LD_LOAD_PATH.
I was using the other flags because someone suggested I use them.
so the gcc i ended up using is this:
# my tree is like this
# cata/*.c
# build/*.dylib
#
cd build
gcc -arch i386 ../cata/*.c -dynamiclib -o cata.dylib
Doing this compiles/makes a library in the same directory where it thinks it is 'used' (basically having no path). I am now free to put it somewhere else. When it is later linked at compile time by a different program and then examined using
otool -L
it appears with no path in front of the library name. This is apparently preferable as now when the system goes to try to find it it resorts to looking at the standard libraries and eventually finds it (because I install it to one of the standard locations).
In the original way, otool -L was showing it having a required path of
'build/cata.dylib'
This made it un-findable and which is why i was trying to use the apple documentation to get around the problem.
This doesn't really solve why LC_ID_DYLIB doesn't work. I looked into the Loader.h file (line 643) and it has room for an identifier(0xd), a path, and a structure, so I don't really understand why my path wasn't getting picked up. but its two different topics. Loader.h is runtime and the other is gcc AFAIK. I'm still learning apple.
I am writing an application that has multiple subdirectories. I have created a Makefile structure such that the subdirectories compile the file and do "ar rvs" and "ranlib libxxx.a" to create archives into the parent directory for linking.
However the "ld" command is running into the following problem.
ld: warning: ignoring file ./libxxx.a, file was built for archive which is not
the architecture being linked (x86_64):
./libxxx.a Undefined symbols for architecture x86_64:
I am using gcc on Mac OS X 10.10.1
I read many posts on this. I tried "gcc -arch i386", then I encounter the same error for i386
Undefined symbols for architecture i386:
I installed gcc-4.9.2 and tried using it instead of the default gcc, with no luck. I tried using x86_64-apple-darwin14.0.0-g++-4.9.2 and that did not help either.
The errors you are seeing mean that you have a mixture of i386 and x86_64 code in the build, and you need to be consistent. Unless there's a compelling reason to do otherwise (I'd be curious to know what it is), you should be compiling everything for 64-bit only. Using gcc on Mac, that is normally the default, but you can force it by adding a -m64 flag to the compilations. One way of doing that is to set CC="gcc -m64" on the make command line; there are other better ways too, but the details depend on your makefile contents.
To resolve: first, remove all the libraries and object code you've built in your project area (maybe make clean will do it — if you wrote a clean target). Then, fettle the value of CC or its flags (CFLAGS ultimately, but how CFLAGS is built depends on the makefile) so that 64-bit compilation is enforced. Then make sure you're using that in all compilations. If you don't see the -m64, you've got a problem.
If you must use 32-bit, substitute -m32 for -m64.
The discussion above assumes you are using gcc to run the ld command. If you are not, then you're on your own until you use gcc to run the ld command. In my view, you've got better things to do with your life than work out how to run the ld command correctly; I certainly have.
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 am trying to compile a C program which uses regexes on FreeBSD. I have checked in /usr/local/include and the file pcre.h is definitely there.
However, no matter what I do, I get the following compiler error:
/usr/home/myname/project/include/pcre_wrap.h:4:18: error: pcre.h: No such file or directory
What could be going wrong? My understanding of C libraries on Unix could be better...
As the comment above says you need to use #include. If this isn't working you may want to export an environment variable C_INCLUDE_PATH that points to the header file.
Failing that why not try adding -I/usr/local/include to your gcc call, something like gcc myfile.c -I/usr/local/include -o myexe
I try to add gsoap in my application.
I built gsoap for i386.
Created c code with under commands:
wsdl2h -c -s -o soap.h soap.wsdl
soapcpp2 -c -C soap.h
I got files. After this I tried to include these to my app.
I added to my project in xCode. Also I added 6 libraries(libgsoap.a,libgsoap++.a,libgsoapck.a, libgsoapck++.a, libgsoapssl.a, libgsoapssl++.a). I added libraries in Target => Build phases => Link binary with libraries.
But I got error....
ld: duplicate symbol .....
I thought it happened cause in file soapClientLib.c was it:
#ifndef WITH_NOGLOBAL
#define WITH_NOGLOBAL
#endif
#define SOAP_FMAC3 static
#include "soapC.c"
#include "soapClient.c"
Comments for these was:
Use this file in your project build instead of the two files soapC.c and soapClient.c. This hides the serializer functions and avoids linking problems when linking multiple clients and servers
I removed it content.
But after this I got next error...
Undefined symbols for architecture i386:
"_namespaces", referenced from:
_soap_init_LIBRARY_VERSION_REQUIRED_20812 in libgsoap.a(libgsoap_a-stdsoap2.o)
(maybe you meant: _soap_set_namespaces, _soap_set_local_namespaces )
ld: symbol(s) not found for architecture i386
clang: error: linker command failed with exit code 1 (use -v to see invocation)
And Now I have no idea...
I used gsoap in windows and I added it to my project for 5 minutes. But I wasted much time to add it in mac os.
Can you help me?
I resolved my problem!
I had to do ./configure with keys --disable-namespaces.
Thank you.
But I steal don't understand sense of the file soapClientLib.c.
I know, that this is an old question, but I've just spent an entire evening figuring this out.
Here is a quote from this conversation (another link):
The soapcpp2-generated xyz.nsmap file should be #include'd in your code. It
contains a global XML namespace mapping (or binding) table.
The reason for including this separately is that there are scenarios where the
namespace mapping table is customized or shared.
For instance, I used a C++ classes, generated with soapcpp2 -i <my_header.h>. One of generated files is a <my_service_name>Service.cpp. To get rid of the _namespaces issue I had to #include "<my_service_name>.nsmap" in it.
As for the soapClientLib.c, I's like to quote that conversation again:
Please do not use soapClientLib.c in your build unless you want to combine
multiple separately-generated clients/server codes. This means that the
soapClientLib.c do not include the shared serializers for SOAP headers and
faults.
This problem can be solved with changing compiler filename from gcc to g++.
GCC:
gcc calcmain.cpp soapC.cpp soapcalcProxy.cpp -I/opt/local/include -lgsoap++ -L/opt/local/lib
...
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
G++:
g++ calcmain.cpp soapC.cpp soapcalcProxy.cpp -I/opt/local/include -lgsoap++ -L/opt/local/lib
All OK
Yet you can make it compilable under gcc, with adding an gcc option -lstdc++:
gcc calcmain.cpp soapC.cpp soapcalcProxy.cpp -I/opt/local/include -lgsoap++ -L/opt/local/lib -lstdc++
All OK