I am trying to compile a simple executable using CMake and Clang on Ubuntu 18. Some code coming from a third party source and compiled as a shared library libtommath ends up calling the function __udivti3 after the compiler does some code optimisations.
At link time, I have an error coming from ld saying hidden symbol "__udivti3" in /usr/lib/gcc/x86_64-linux-gnu/7/libgcc.a(_udivdi3.o) is referenced by DSO
I did some research and thanks to this link this effectively means that __udivti3 is referenced by the shared library but It cannot be used from the libgcc.a as it is marked as hidden in this library.
My issue is whatever I try to fix it, the linkage always fails. I tried to link with libgcc_s which is located in the same directory but clang complains it cannot find it. On the other hand though, the compilation and linkage work perfectly on MacOS, with that problematic symbol still being present.
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'm rather unused to C, and completely new to compiling bigger projects, and I'm having problems trying to build GNU Archimedes.
I tried the ./configure and make approach, as well as simply executing gcc -lm archimedes.c -o archimedes in the src/ directory, as the documentation suggests. Both give a similar error message:
Undefined symbols for architecture x86_64:
"_MM2", referenced from:
_ParabMEP2D in ccwORAXj.o
_Hole_MEP2D in ccwORAXj.o
"_creation", referenced from:
_EMC in ccwORAXj.o
"_rnd", referenced from:
_MCdevice_config in ccwORAXj.o
_scat in ccwORAXj.o
_EMC in ccwORAXj.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status
MM2, rnd, and creation are functions contained in one of many .h files in src/. Every solution to similar sounding problems had issues linking multiple compiled .c files together, but in this case, there's only one .c file.
If it's relevant, the name of the .o file in the error changes with every try.
I've tried building it under macOS (with both clang and gcc, the latter installed via Homebrew) and Fedora Linux, with similar results.
What am I doing wrong? I hope this is the right place to ask, but I have no idea where else to turn. I'm grateful for suggestions.
Thanks in advance and have a good day!
In the folder /archimedes-2.0.1/src/ go through all header files (.h) and change every "inline" to say "static inline".
This fix was found by Alexander Vogt. His original post is linked to below:
https://lists.gnu.org/archive/html/archimedes-discuss/2017-11/msg00000.html
The problem has to do with compatibility issues between older and newer versions of c compilers.
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.
I have successfully built Clang with Microsoft C++ and I'm trying to get it to compile a hello world test case; it gets as far as generating an object file, linking with the standard library being the remaining stumbling block:
hello-202520.o : error LNK2019: unresolved external symbol _printf referenced in function _main
LINK : error LNK2001: unresolved external symbol _mainCRTStartup
There are comments from previous years saying Clang doesn't yet do Windows linking at all, but I get the impression those are outdated, and indeed it does now seem to be able to generate Windows format object files:
clang -c hello.c
ren hello.o hello.obj
link hello.obj
... doesn't barf, so the file format seems to be correct, but still gets the unresolved external symbol errors. Likely guess is the Microsoft compiler tags its output object files with an indication of the standard library they need to be linked with whereas Clang doesn't, and eyeballing a hex dump of the respective object files seems to confirm this and gives a hint of the linker command line to use:
link /defaultlib:libcmt /defaultlib:oldnames hello.obj
I had high hopes by this stage but alas it still gives the same unresolved external symbol errors.
What am I still missing?
Turns out Clang was by default generating 32-bit code but I was using 64-bit MSC, and the leading _ on C symbols has been dropped with the move to x64, so specifying -m64 on the clang command line did the job.
I have a c program that calls sin, cos, and acos. When I compile I get the following errors:
/tmp/ccDfW98S.o: In function `zip_search':
main.c:(.text+0xf30): undefined reference to `sin'
main.c:(.text+0xf45): undefined reference to `sin'
main.c:(.text+0xf66): undefined reference to `cos'
main.c:(.text+0xf7b): undefined reference to `cos'
main.c:(.text+0xf9c): undefined reference to `cos'
main.c:(.text+0xfc6): undefined reference to `acos'
collect2: ld returned 1 exit status
I know this is common when you don't use the -lm gcc flag. I AM using this flag. I'm calling GCC like this:
gcc -o zipcode-server -lm main.c
When I compile on one of my computers this works fine. The only difference that I can think of is that this isn't working on x86_64 and the computer it does work on is i686. Both are Ubuntu. The file libm.a is present on the computer it isn't working on and I don't get any errors saying it can't be found. What could be causing this?
You should put -lm after main.c
In general, if you have multiple libraries, they should be written in order of their usage. For example, if library A uses library B, you should have -lA -lB.
In your case, the object file that is the result of compilation of main.c uses library m and therefore -lm should come after it.
For the curious, this is mostly for efficiency reasons. With this scheme, the linker can resolve currently unknown symbols with every new library seen in the argument list, and picking up new unknown symbols from that library on the way. This means that the linker can visit the libraries one by one, and therefore match the unknown symbols against a small number of symbols provided by each library.
On the contrast, the linker could load in symbols from all libraries at once, and then start matching unknown symbols. In that case however, the linker needs to deal with a much greater number of symbols, increasing both the memory footprint and the execution time of the linker.
Since the libraries could always be declared to the linker in the proper order of their dependencies1, there is no reason for the linker to choose the inefficient way.
1 Libraries normally have a one-way relationship, in the sense that one uses the other. Circular dependencies between libraries is rare, if at all existing, but it could still be used with this model by repeating certain libraries to be reinspected.