When linking an executable on Linux i get an 'undefined reference' error like this:
undefined reference to `symbol#SOMELIB_1.0'
I do not have a control of 'SOMELIB', but I do have the symbol symbol in one of my own shared libraries. I'm absolutely sure that the symbol#SOMELIB_1.0 is the same (provides exactly the same functionality) that the symbol in my library, actually even the source code is almost the same.
How to force/alias the symbol#SOMELIB_1.0 to be linked from my library, not from SOMELIB_1.0 ?
I was thinking about some kind of symbol versioning tricks in linker script, but I could not find any solution or even clues.
Thanks in advance.
After loooong fight (and search) I found a solution here.
To summarize: I needed two symbols. In my source code I put something like this:
__asm__(".symver symbol1, symbol1#SOMELIB_1.0");
void symbol1(void)
{
.....
}
__asm__(".symver symbol2, symbol2#SOMELIB_1.0");
void symbol2(void)
{
.....
}
Then I needed a liker script mylib.map containing:
SOMELIB_1.0 {
symbol1;
symbol2;
};
To link "mylib.so" I needed to pass additional argument: -Wl,--version-script=mylib.map
Related
I currently need to call a C++ function in my Flutter project, for a Linux desktop application (using dart:ffi). This page https://flutter.dev/docs/development/platform-integration/c-interop#first-party-library doesn't explain how to configure this kind of projects on Linux (neither for Windows).
After a few try, I'm unable to correctly link the C++ library.
The C++ Function
#include<iostream>
extern "C" {
void do_something(const char *program_name, const char *password)
{
//Do something with data
}
}
I added the following lines to the CMakeLists.txt :
add_library(my_native STATIC ../native_lib/my_native.cpp)
target_link_libraries(${BINARY_NAME} PUBLIC my_native)
And finally, I'm linking in Dart the following way :
// Since the CMake code was added in the executable CMakeLists.txt, it seems that it
// is supposed to be done that way, with DynamicLibrary.executable() rather than DynamicLibrary.process()
// method
final DynamicLibrary lib = DynamicLibrary.executable();
final doSomethingFuncPointer = lib.lookup<NativeFunction<do_something_signature>>("do_something");
It compiles fine, but at startup, the program returns the following error :
[ERROR:flutter/lib/ui/ui_dart_state.cc(171)] Unhandled Exception: Invalid argument(s): Failed to lookup symbol (/home/me/Documents/flutter/desktop_installer_framework/build/linux/debug/bundle/installer: undefined symbol: do_something)
I also tried with dynamic linking (marking the library as SHARED in CMakeLists.txt and linking it with DynamicLibrary.open("libmy_native.so")). Also tried calling DynamicLibrary.process() and putting the CMake lines inside the second CMakeLists.txt (the one in linux/flutter). It never finds symbols. So, I think I'm missing something here.
Any help would be appreciated.
Best regards
You've shown the definition; is that also the declaration? If so (which seems likely since you have the extern there) you are missing the visibilty and used annotations that the page you linked to described needing for C++, which would explain why the symbol isn't in the resulting binary.
I have downloaded libgcrypt library source code and I want to customize this standard shared library by adding my function inside one particular
source code file .
Although compilation/build process of customized shared library is successful, but it shows error at linking time.
Here is what I have done .
inside /src/visibility.c file, I have added my custom function,
void MyFunction(void)
{
printf("This is added just for testing purpose");
}
I have also include function prototype inside /src/gcrypt.h
void MyFunction(void);
#build process
./configure --prefix=/usr
sudo make install
nm command find this custom function.
nm /usr/lib/libgcrypt.so | grep MyFunction
000000000000dd70 t MyFunction
Here is my sample code to access my custom function.
//aes_gcrypt_example.c
#include <stdio.h>
#include <gcrypt.h>
#include <assert.h>
int main()
{
MyFunction();
return 0;
}
gcc aes_gcrypt_example.c -o aes -lgcrypt
/tmp/ccA0qgAB.o: In function `main':
aes_gcrypt_example.c:(.text+0x3a2): undefined reference to `MyFunction'
collect2: error: ld returned 1 exit status
I also tried by making MyFunction as extern inside gcrypt.h, but in that case also I am getting same error.
Why is this happening ?
Is the customization of standard library is not allowed ?
If YES, then is there any FLAG to disable to allow customization ?
If NO, what mistake I am making ?
It would be great help if someone provide some useful link/solution for the above mentioned problem. I am using Ubuntu16.04 , gcc 4.9.
Lower-case t for the symbol type?
nm /usr/lib/libgcrypt.so | grep MyFunction
000000000000dd70 t MyFunction
Are you sure that's a visible function? On my Ubuntu 16.04 VM, the linkable functions defined in an object file have T (not t) as the symbol type. Is there a stray static kicking around and causing confusion? Check a couple of other functions defined in libgcrypt.so (and documented in gcrypt.h) and see whether they have a t or a T. They will have a T and not t. You'll need to work out why your function gets a t — it is not clear from the code you show.
The (Ubuntu) man page for nm includes:
The symbol type. At least the following types are used; others
are, as well, depending on the object file format. If lowercase,
the symbol is usually local; if uppercase, the symbol is global
(external).
The line you show says that MyFunction is not visible outside its source file, and the linker agrees because it is not finding it.
Your problem now is to check that the object file containing MyFunction has a symbol type T — if it doesn't the problem is in the source code.
Assuming that the object file shows symbol type T but the shared object shows symbol type t, you have to find what happens during the shared object creation phase to make the symbol invisible outside the shared object. This is probably because of a 'linker script' that controls which symbols are visible outside the library (or maybe just compilation options). You can search on Google with 'linker script' and various extra words ('tutorial', 'provide', 'example', etc) and come up with links to the relevant documentation.
You may need to research documentation for LibTool, or for the linker BinUtils. LibTool provides ways of manipulating shared libraries. In a compilation command line that you show in a comment, there is the option -fvisibility=hidden. I found (mostly by serendipitous accident) a GCC Wiki on visibility. See also visibility attribute and code generation options.
I have a problem with an embedded linux C++ application I've written that consists of an executable and a dynamically linked library. The executable calls a function that is one of the entry points in the library, but that function misbehaves. I've investigated using gdb, and find that the library function, which is supposed to make a call to another function xyz() within the library, actually calls a function of the same name xyz()within the executable.
I'm very surprised this can happen, so maybe I'm doing something stupid. Isn't the library linked within itself without reference to the executable? If the executable wrongly made a call to abc() in the library instead of abc() in the executable that would make slightly more sense, because it is at least linked with the library, although in that case would the linker spot the dual definition? Or prioritise the local function?
I could just rename my functions so none of them have matching names, but I'd like to understand what is going on. I don't have much experience in this area, or with the gcc tools. Firstly, is what I think is happening in the above scenario even possible?
Both the executable and the library make calls to another library.
The link command for the library I'm using is:
powerpc-unknown-linux-gnuspe-g++-4.9.3 aaa.o bbb.o [etc] -shared -o libmylibary.so -L ../otherlibpath -Wl,-rpath-link,../otherlibpath -lotherlibname
That is way how the dynamic linker works. The symbols in executable have higher priority then symbols in dynamic libraries. Dynamic library designer must be aware about it. She must do measures to avoid unwanted symbol mismatch. Most libraries use:
In case of C++ use namespaces. All symbols exported from library should be in a library namespace.
In case of C use a name prefix or suffix for all exported symbol. For example OpenSSL library uses the prefix SSL_ and the public functions have names like SSL_set_mode() so the unwanted symbol collision is avoided.
Do not export symbols from the library that are supposed to be private. If the symbol is not exported from the library then the dynamic linker use the local symbol in the library. #pragma visibility is your friend. See https://gcc.gnu.org/wiki/Visibility
If the library with duplicate symbols is a 3rd party library and its author does not follow the recommendations above then you have to rename your function or perhaps ask the author for a library update.
EDIT
Export/do not export may be controlled by #pragma visibility directive (gcc specific extension):
void exported_function1(int);
void exported_function2(int);
#pragma GCC visibility push(hidden)
void private_function1(int);
void private_function2(int);
#pragma GCC visibility pop
Detail at the link above.
I can't, for the love of God, to static link the ZLIB libs. I have been struggling for a couple hours now with no success. Well, I have followed this tutorial and successfuly compiled both zlibstat.lib and zlibwapi.lib for 32 bits. After setting up my project to use the ZLIB folder with the libraries (Linker > General > Additional Library Directories) and setting zlibwapi.lib (only) as an dependency (Linker > Input > Additional Dependencies) I got it to work, however, that was a dynamic link (I need to distribute my application with the ZLIB dll). I usually use dynamic linking on Debug and static on Release.
I have tried looking for what the hell is the zlibstat.lib and whats it used for, if not for static linking, assuming the "stat" suffix.
Are there any preprocessor to be added into my project, something like ZLIB_STATIC or something, to use static linking of ZLIB or should I have never removed the ZLIB_WINAPI from the zlibstat project, just like the above link told me to do? Is it impossible to static link ZLIB (then, whats zlibstat.lib for?)?
I am pretty lost. Any help is GREATLY appreciated.
Edit (Extra information):
Errors:
error LNK2001: unresolved external symbol _inflateInit_#12
error LNK2001: unresolved external symbol _inflate#8
error LNK2001: unresolved external symbol _inflateEnd#4
Linking:
Unlike the dynamic link (that worked) where I added zlibwapi.lib as a dependency, for the static linking I'm trying to achieve I added zlibstat.lib as a dependency instead! No other libs were added!
This question might look like this (kind of).
I have finally managed to solve my problem. For those that end up in such a problem, heres how to solve it:
If you followed the tutorial in my first post, you would have removed ZLIB_WINAPI from the zlibstat project's Preprocessor. However, after setting up my own project (setting ZLIB dependencies path, LIB dependencies libraries etc) that uses ZLIB, I 'accidently' included/defined the damned ZLIB_WINAPI macro in the header file I'm using ZLIB, right before including "zlib.h".
One curious thing about this is that when launching the app on debug mode (which was using dynamic linking), everything succeeded and worked like a charm, without any warnings or whatsoever, HOWEVER, on release mode (which was using the static linking), it crashed.
So, to clear things up, the tutorial tells us to remove the ZLIB_WINAPI preprocessor from the zlibstat project, which produces the static lib, whilst the zlibvc project has the ZLIB_WINAPI in its preprocessor. In other words, that means that if we're using different linkings for each configuration (debug/release), we have to add the ZLIB_WINAPI macro or not!
Define the ZLIB_WINAPI macro before including "zlib.h" if youre using dynamic linking (zlibwapi.lib) and that the zlibvc project remains unmodified (assuming you correctly followed the tutorial from the link above) and do not define it if you removed ZLIB_WINAPI from the zlibstat project (like the tutorial tell us to)!
One helpful macro I used on my own project is as follows:
// Since we used dynamic linking for debug, we have to define the ZLIB_WINAPI
#if defined(_WIN32) && defined(_DEBUG)
#define ZLIB_WINAPI
#endif
#include <zlib.h>
Things got really confusing and I really hope I was clear enough.
I have a few logging functions that I commonly use for different Arduino programs. Since I use them so much, I decided to try to make a custom library for them. Unfortunately, the compiler crashes at the header file with the error:
unknown type name 'String'
I'm a bit confused as to why this is happening because I am including the standard Arduino libraries (which I believe should contain the String class) at the top of my header. Here's the whole thing:
#ifndef logging_h
#define logging_h
#include "Arduino.h"
void logEvent(String msg);
void debugOut(String msg);
void errOut(String err);
void document(String parameter, float value);
#endif
I reinstalled the Arduino IDE (1.0.5) so I think I should have the most recent standard library. If anyone has some suggestions I would really appreciate it.
(This answer is based on our discussion in comments.)
The problem was that the source file for your library was named *.c. That caused the compiler to treat it as C code instead of C++, which means it couldn't handle classes/objects (such as String).
Naming the file *.cpp instead lets the compiler treat it correctly as C++ code.
I had same issue yesterday. The code you included in your question should be your .h file, isn't? My question is: is your library written in C or in C++?
I assume you use C code.
You can't import code from in a user C library with the Arduino IDE. The reason is that use C++ code, and it can't be called from your C library.
Solution: rewrite your library in C+, it's not too difficult.
You can find a lot of help on google on how to write library in C++. You can also check my example at https://github.com/romain-viollette/AverageFilter/
best regards,