For a project I am dependend on a certain libary. This library needs to do something with the serial interrupt which is fine on it's own. I tested the library and what it is supposed to do, functions perfectly fine.
But than I included <SD.h> and than this happened.
HardwareSerial0.cpp.o (symbol from plugin): In function `Serial':
(.text+0x0): multiple definition of `__vector_18'
I know precisely what is going on. These lines of my custom library
#elif defined(SERIAL_PORT_0)
ISR(USART_RX_vect) {
XpressNetClass::handle_interrupt(); //weiterreichen an die Funktion
}
conflicts somehow with the Sd.h library.
Now I looked into the SD library to see if I can 'remove' any conflicting code but I cannot find it. I looked into several header files which were mentioned in the sd library.. but it is such a large web with files I get lost.
I found the only other mentioning of
ISR(USART_RX_vect)
and it lies in HardwareSerial0.cpp. But I do not understand how SD.h ends up with using hardwareSerial0 somehow?
So I have 2 questions: Is this actually fixable? I would like to use both SD and SPI libraries and my custom library needs to do it's thing as well.
And if it is fixable. How can I fix this without breaking every other project?
I am compiling the code for an atmega328P.
The problem lies within the folder in which the SD.h library lies. In this folder there is a file called SDfile.cpp and it contained one whole function with a couple of calls to Serial.print.
Commenting out all these lines, solves the conflict.
Related
I've been writing a Python extension use the Python/C API to read data out of a .ROOT file and store it in a list of custom objects. The extension itself works just fine, however when I tried to use it on a different machine I ran into some problems.
The code depends upon several libraries written for the ROOT data manipulation program. The compiler is linking these libraries dynamically, which means I cannot use my extension on a machine that does not have ROOT installed.
Is there a set of flags that I can add to my compilation commands to make these libraries statically linked? Obviously this would make the file size much larger but that isn't much of an issue providing that the code runs at the same speed.
I did think about collating all of the ROOT libraries that I need into an 'archive' file. I'm not too familiar with this so I don't know if that's a good idea or not.
Any advice would be great, I've never really dealt with the static/dynamic library issue before.
Thanks, Sean.
This might seem like a strange idea, but I need the same library linked into my code twice.
A bit of background: I am writing a bit of firmware with a bootloader and a application. Both bits of code need to use the comms library (spi) and some other system libs to run. I cannot replace those libraries in the bootloader if it is using those libraries to run. Hence I would like to include the lib twice, once for the bootloader, and once for the application.
Previously I have done this by making two programs and splicing the HEX files as part of the build process. This time I would like to make one elf that contains both application and bootloader (with debugging symbols for both). Then I can generate the boot load image by stripping it out in a post build step. This allows me to build a complete image and use the linker to avoid collisions etc without making my own tool, and means I can debug errors in the bootloader and the application easily, but the only stumbling block would having the lib multiple times
I figure a solution might be to make two separate static libs ie bootloader.a and application.a the both already contain the other lib, but this seems messy. Does anyone know a better solution?
I'm quite confused about linking tips. Supose I have an app that uses a dll, but I do not want to use it, I want to statically link with a lib and avoid the dependency for the dll. Is it possible?
It's impossible enough not to try if you want a solution to your problems instead of a bunch of new problems.
(I've managed to make something like that work a couple of times. One variant used a MemoryModule and loading from memory, another one used a heuristic to find cross-segment relocations and fix them up to re-separate code and data sections. Neither was remotely like something you may recommend to a person confused about linking tips).
My project is using ACE library, and need link another library libsdk.so, it's using another version ACE library.
The link order like : ...-lMyAce -lsdk -lAnotherAce
When application running, libsdk.so called method in MyAce(I checked the core dump), and the application crash.
If I change link order to: ...-lsdk -lAnotherAce -lMyAce
My code called method in AnotherAce, it's also crash.
If I only link my ACE, it's crash. There are some link error if only link AnotherAce.
Let the libsdk.so call its ACE library, and my code call my ACE library.
How can I resolve the problem?
The Solaris linker has an option that may help, though really redesigning your application to not need two sets of libraries with the same names in the same program
is going to be the best solution.
Direct Bindings record in each library or program which library it found a symbol in, so if libsdk.so is built with -B direct -lAnotherAce, it will record each of its references go to AnotherAce, not MyAce. You'd then link your code with -B direct -lsdk -lMyAce (do not include -lAnotherAce, as the libsdk dependencies take care of that), and your code would record that it's calls to to MyAce.
I have an application with a plug-in architecture that is using Boost.Threads as a DLL (specifically, a Mac OS X framework). I am trying to write a plug-in that uses Boost.Threads as well, and would like to link in the library statically. Everything builds fine but the application quickly crashes in my plug-in, deep within the Boost.Threads code. Linking to the DLL version of Boost.Threads seems to resolve the problem, but I'd like my plug-in to be self-contained.
Is it possible to have two instances of Boost.Threads with such a setup (one as a DLL, one statically linked in another DLL)? If so, what might I be missing to make the two instances get along?
Once my team faced a similar problem. For reasons I will not mention at this time, we had to develop a system that used 2 different versions of Boost (threads, system, filesystem).
The idea we came up with and executed was to grab the source code of both versions of Boost we needed, and then tweak one of them to change the symbols and function names to avoid name clashing.
In other words, we replaced all references to the name boost for bubbles inside the sources (or some other name) and also made changes to the compilation so it would build libbubbles instead of libboost.
This procedure gave us 2 sets of libraries, each with having their own binaries and header files.
If you looked at the source code of our application you would see something like:
#include <bubbles/thread.hpp>
#include <boost/thread.hpp>
bubbles::thread* thread_1;
boost::thread* thread_2;
I imagine some of the guys here already faced a similar situation. There are probably better alternatives to the one I suggested above.