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
Related
I am attempting to compile a C program on macOS Catalina. The program will make use of bzip2 decompression. My code includes the line
#include <bzlib.h>
and I am trying to call the function BZ2_bzBuffToBuffDecompress. However, when I run gcc myfile.c -o myfile.c.o, I get the following error:
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1
I am just using a plain text editor and gcc, no IDEs and no CMake files. I suspect I may need a CMake file for this but I am not really sure how to proceed. Any assistance with this is greatly appreciated!
You need to link in the bzip library. gcc myfile.c -o myfile -lbz2. That command assumes the lib is installed into the standard location. Also, you are compiling a final executable so (by strong convention) it should not have a .o suffix.
I have two directories, sorting and searching (children of the same directory), that have .c source files and .h header files:
mbp:c $ ls sorting
array_tools.c bubble_sort.c insertion_sort.c main selection_sort.c
array_tools.h bubble_sort.h insertion_sort.h main.c selection_sort.h
mbp:c $ ls searching
array_tools.c array_tools.h binary_search.c binary_search.h linear_search.c linear_search.h main main.c
Within searching, I am building an executable that needs to use insertion_sort function, declared in insertion_sort.h and defined in insertion_sort.c inside sorting. The following compilation successfully produces an executable:
mbp:searching $ clang -Wall -pedantic -g -iquote"../sorting" -o main main.c array_tools.c binary_search.c linear_search.c ../sorting/insertion_sort.c
However, I would like to be able to include functions from arbitrary directories by including a header using #include and then providing the compiler with the search path. Do I need to precompile the .c files to .o files beforehand? The man page for clang lists the following option:
-I<directory>
Add the specified directory to the search path for include files.
But the following compilation fails:
mbp:searching $ clang -Wall -pedantic -g -I../sorting -o main main.c array_tools.c binary_search.c linear_search.c
Undefined symbols for architecture x86_64:
"_insertion_sort", referenced from:
_main in main-1a1af0.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
main.c has the following includes:
#include <stdio.h>
#include <stdlib.h>
#include "linear_search.h"
#include "binary_search.h"
#include "array_tools.h"
#include "insertion_sort.h"
I do not understand the link between header files, source files, and object files. To include a function defined in a .c file, is it sufficient to include the homonymous header file, given that the .c file is in the same directory as the header? I have read multiple answers here on SO, the man page for clang and a number of tutorials, but was unable to find a definitive, clear answer.
In response to #spectras:
One by one, you give the compiler a source file to work on. For instance:
cc -Wall -Ipath/to/some/headers foo.c -o foo.o
Running
mbp:sorting $ clang -Wall insertion_sort.c -o insertion_sort.o
produces the following error:
Undefined symbols for architecture x86_64:
"_main", referenced from:
implicit entry/start for main executable
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Okay, it's mixed up a bit. Let's see how one typically compiles a simple multi-file project.
One by one, you give the compiler a source file to work on. For instance:
cc -c -Wall -Ipath/to/some/headers foo.c -o foo.o
The -c flag tells the compiler you want an object file, so it should not run the linker.
The compiler runs the preprocessor on the source file. Among other things, every time it sees a #include directive, it searches the include paths for named file and basically copy-pastes it, replacing the #include with the content. This is done recursively.
This is the step where all .h you include get merged into the source file. We call the whole thing a translation unit.
You can see the result of this step by using -E flag and inspect the result, for instance:
cc -Wall -Ipath/to/some/headers foo.c -E -o foo.test
Let's make this short as other steps are not relevant to your question. The compiler then creates an object file from the resulting source code. The object file contains binary version of all code and data that was in the translation unit, plus metadata that will be used to put everything together and some other stuff (like debugging info).
You can inspect the contents of an object file using objdump -xd foo.o.
Note that as this is done for each source file, this means that headers get parsed and compiled again and again and again. That's the reason they should only declare stuff and not contain actual code: you would end up with that code in every object file.
Once done, you link all the object files into an executable, for instance:
cc foo.o bar.o baz.o -o myprogram
This step will gather all, resolve dependencies and write everything into an executable binary. You may also pull in external object files using -l, like when you do -lrt or -lm.
For instance:
foo.c includes bar.h
bar.h contains a declaration of function do_bar: void do_bar(int);
foo.c can use it, and compiler will generate foo.o correctly
foo.o will have placeholders and the information that it requires do_bar
bar.c defines the implementation of do_bar.
so bar.o will have the information “hey if anyone needs do_bar, I got it here”.
linking step will replace placeholders with actual calls to do_bar.
Finally, when you pass multiple .c files to the compiled like you do in your question, the compiler does basically the same thing, only it won't generate the intermediate object files. Overall process behaves the same though.
So, what about your error?
Undefined symbols for architecture x86_64:
"_insertion_sort", referenced from:
_main in main-1a1af0.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
See? It says linking step failed. That means previous step went well. The #include worked. It's just in the linking step, it's looking for a symbol (data or code) called _insertion_sort, and does not find it. That's because that symbol was declared somewhere (otherwise source using it would not have compiled), but its definition is not available. Either no source file implemented it, or the object file that contains it was not given to the linker.
=> You need to make _insertion_sort's definition available. Either by adding ../sorting/insertion_sort.c to the source lists you pass or by compiling it into an object file and passing that. Or by building it into a library so it can be shared by your two binaries (otherwise they'll each have a copy embedded).
When you get there, usually starting to use a build toolsuite such as CMake is a good idea. It will take care of all the details for you.
I just started to learn gcc/g++ by reading "An introduction to GCC"
In chapter 3.1 the author showed an example of linking with external libraries and header files. The main source code uses 'gdbm.h' header (installed at /opt/gdbm-1.8.3/include/ in text book) file and the library ‘libgdbm.a’ (installed at /opt/gdbm-1.8.3/lib/ in text book). The process of linking with the library and header file is as follows:
Link to example screenshot
When I tried to repeat this, I got a contradictory result. When I used method 1 (in the example fails) which only includes header file path, the program can be compiled, however, when I used method 2 (in the example succeeds), I got an error, saying that
"ld: 1 duplicate symbol for architecture x86_64
clang: error: linker command failed with exit code 1"
(this is my full command line and error message:)
userMacBook-Pro:03 user$gcc -Wall -I/usr/local/include dbmain.c -L/usr/local/lib dbmain.c -lgdbm
duplicate symbol _main in:
/var/folders/6_/09vfzzms7dq1d73vl4mwlxmh0000gn/T/dbmain-9d15f9.o
/var/folders/6_/09vfzzms7dq1d73vl4mwlxmh0000gn/T/dbmain-907e96.o
this is my command that succeeds:
userMacBook-Pro:03 user$ gcc -Wall -I/usr/local/include dbmain.c -lgdbm
userMacBook-Pro:03 user$ ./a.out
Storing key-value pair... done.
ld: 1 duplicate symbol for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Can anyone explain why this happens?
I don't know which platform the author uses, I just use mac OS X.
gcc -Wall -I/usr/local/include dbmain.c -L/usr/local/lib dbmain.c -lgdbm
The file dbmain.c is present twice on your command line. For this reason the main function is present twice.
I'm trying to set up default compiler, linker, etc for a build script. I currently have this:
CC="gcc -std=gnu99 -c"
XX="g++ -std=gnu++11 -c"
LD="gcc"
This works fine, but gives me no warning if I accidentally pass a .c file to $LD, leaving a landmine for anyone who tryes to use a different LD. I'd like to use LD="gcc -x [object]", but gcc documentation doesn't list any name to use for [object]. (I've also tryed LD="ld" of course, but that produces such lovely errors as ld: cannot find -lstdc++ and (after adding -lc) ld: warning: cannot find entry symbol _start; defaulting to 0000000000400e60.)
I am trying to create a dynamic library which is meant to be linked and loaded into a host environment at runtime (e.g. similar to how class loading works in Java). As such, I want the dynamic library to be left with a few "dangling" references, which I expect it to pick up from its host environment when it is loaded into that environment.
My problem is that I cannot figure out how to create the dynamic library without explicitly linking it to existing symbols. I am hoping to produce a dynamic library that does not depend on a specific host executable (or host library), rather one that is able to be loaded (e.g. by dlopen) in any host as long as the host makes a couple symbols available for use.
Right now, any linking command I've tried results in a complaint of missing symbols. I'd like it to allow symbols to be missing (ideally, just particularly specified symbols).
For example, here's a transcript with the error on OS X:
$ cat frotz.c
void blort(void);
void run(void) {
blort();
}
$ cc -c -o frotz.o frotz.c
$ cc -dynamiclib -o libfrotz.dylib frotz.o
Undefined symbols for architecture x86_64:
"_blort", referenced from:
_run in frotz.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
If I do the same thing using a GNU toolchain (on Linux), it helpfully tells me:
$ gcc -shared -o libfrotz.so frotz.o
/usr/bin/ld: frotz.o: relocation R_X86_64_PC32 against undefined symbol `blort'
can not be used when making a shared object; recompile with -fPIC
and indeed, adding -fPIC to the C compile command seems to fix the problem in that environment. However, it doesn't seem to have any effect in OS X.
All the other dynamic-linking questions I could find on SO seem to be about the more usual arrangement of libraries, where a library is being built to be linked into an executable before that executable runs, rather than the other way around. The closest related question I found was this:
Can an executable be linked to a dynamic library after its built?
which unfortunately has very little info, none of it relevant to the question I'm asking here.
UPDATE: I distilled the info from the answer along with everything else I'd figured
out, and put together this example:
https://github.com/danfuzz/dl-example
As far as my knowledge goes, you want to use weak linkage:
// mark function as weakly-linked
extern void foo() __attribute__((weak));
// inform the linker about that too
clang -dynamiclib -o bar.dylib bar.o -flat_namespace -undefined dynamic_lookup
If a weak function can be resolved at runtime, it will then be resolved. If it can't, it will be NULL, instead of generating a runtime (or, obviously, link-time) error.