According to https://groups.google.com/forum/?fromgroups#!msg/android-ndk/J3lzK4X–bM/4YaijymZy_AJ Yes, and this is the documented behaviour: you must load libraries in reverse dependency order explicitely. […] It is a limitation of the system. In a nutshell, the dynamic linker doesn’t know anything about your application (e.g. where its libraries live), it only knows about the LD_LIBRARY_PATH value that was set when … Read more
You are violating C’s “one definition rule”, and the result is undefined behavior. The “one definition rule” is not formally stated in the standard as such. We are looking at objects in different source files (aka, translation units), so we concerned with “external definitions”. The “one external definition” semantic is spelled out (C11 6.9 p5): … Read more
All the issues I had, that were giving Undefined symbols for architecture x86_64 were due to the fact that some libraries were compiled with libstdc++ and could not be used for code that is compiled/linked with libc++ libc++ is in fact the default new library used by clang since Mavericks, however it is possible to … Read more
Minimal runnable example Here I produce a minimal example and compile it in two ways to produce functionally identical executables: one combined f12.c file without partial linking linking into f12.o two separate f1.c and f2.c which are first partially linked into f12_r.o main.c #include <assert.h> #include <stdlib.h> int f_1_2(void); int f_2_1(void); int main(void) { assert(f_1_2() … Read more
It turns out my original attempt was mostly there. The following works: extern “C” void Af(void); void (*Af_fp)(void) = &Af; For those that want a self-contained preprocessor macro to encapsulate this: #if defined(_WIN32) # if defined(_WIN64) # define FORCE_UNDEFINED_SYMBOL(x) __pragma(comment (linker, “/export:” #x)) # else # define FORCE_UNDEFINED_SYMBOL(x) __pragma(comment (linker, “/export:_” #x)) # endif #else … Read more
We can use patchelf: patchelf –replace-needed liboriginal.so.1 libreplacement.so.1 my-program We can also remove a dependency: patchelf –remove-needed libfoo.so.1 my-program Add a dependency: patchelf –add-needed libfoo.so.1 my-program Or change the path where to search for the libraries (rpath): patchelf –set-rpath /path/to/lib:/other/path my-program
The answer is there: https://mathematica.stackexchange.com/questions/34692/mathlink-linking-error-after-os-x-10-9-mavericks-upgrade There are two implementations of the standard C++ library available on OS X: libstdc++ and libc++. They are not binary compatible and libMLi3 requires libstdc++. On 10.8 and earlier libstdc++ is chosen by default, on 10.9 libc++ is chosen by default. To ensure compatibility with libMLi3, we need to choose … Read more
The answer to this question is quite complex since there are various approaches to memory allocation depending on variable scope, size and programming environment. Stack allocated variables Typically local variables are put on the “stack”. This means that the compiler assigns an offset to the “stack pointer” which can be different depending on the invocation … Read more
In the case of rpath, it makes no sense to use a relative path, since a relative path will be relative to the current working directory, NOT relative to the directory where the binary/library was found. So it simply won’t work for executables found in $PATH or libraries in pretty much any case. Instead, you … Read more
I’ve looked at the toolkit you linked, just to read the following in the readme.txt: This toolchain is built and optimized for Cortex-R/M bare metal development. In other words, this toolchain is specifically configured for embedded systems, perhaps with no operating system running at all. In such case, there’s no system to provide e.g. standard … Read more