I have a custom library that utilises this code (https://www.dropbox.com/s/iwft7snjmntf160/SoASpriteFont.zip?dl=0).
The linked code was written for Visual Studio; I am using CodeLite on Windows.
Its has a SpriteFont.cpp that uses fprintf.
The static library that has SpriteFont as part of it compiles fine on its own and produces a *.a quite happily.
However when I use SpriteFont via other code, I get a linker error (if I am not mistaken):
D:/Coding/TDM-GCC-32/bin/g++.exe -o ./Debug/tmp #"tmp.txt" -L. -L../deps/lib/ -L../bengine/lib/ -lbengine -lSDL2_ttf -lSDL2main -lSDL2 -lopengl32 -lglew32
D:/Coding/TDM-GCC-32/bin/../lib/gcc/mingw32/5.1.0/../../../libmsvcrt.a(dsnos00619.o):(.text+0x0): multiple definition of `fprintf'
../bengine/lib//libbengine.a(SpriteFont.cpp.o):D:/Coding/TDM-GCC-32/include/stdio.h:243: first defined here
I have read all over and found some similar situations but nothing that I have managed to use to resolve this.
It sounds like there is an issue with the way TDM-GCC redefines fprint in its' stdio.h, but I can't see how. Upon further examination, I believe the problem may lie with SDL_ttf, which is used by SpriteFont.
Also, I have tried using other functions from stdio.h and they compile fine; problem only seems to be fprintf
I have tried to create a barebones program to illustrate the problem. Hope it helps. Hopefully the fact it is a CodeLite project won't be a source of irritation.
If I can provide more info or code please ask.
This usually happens in MinGW when linking against a dll file that also has file in the form of <NAME>.dll.a
To fix this, just link against the dll directly (I recently encountered the same problem when build LLDB debugger on Windows /w MinGW, the solution was to link directly against the dll file and delete the dll.a file
Related
I'm trying to compile CMake using a non-default GCC installed in /usr/local/gcc530, on Solaris 2.11.
I have LD_LIBRARY_PATH=/usr/local/gcc530/lib/sparcv9
Bootstrap proceeds fine, bootstrapped cmake successfully compiles various object files, but when it tries to link the real cmake (and other executables), I get pages of "undefined reference" errors to various standard library functions, because, as running the link command manually with -Wl,-verbose shows, the linker links with /usr/lib/64/libstdc++.so of the system default, much older GCC.
This is because apparently CMake tries to find curses/ncurses libraries (even if I tell it BUILD_CursesDialog:BOOL=OFF), finds them in /usr/lib/64, and adds -L/usr/lib/64 to build/Source/CMakeFiles/cmake.dir/link.txt, which causes the linker to use libstdc++.so from there, and not my actual GCC's own.
I found a workaround: I can get the path to proper libraries from $CC -m64 -print-file-name=libstdc++.so then put it with -L into LDFLAGS when running ./configure, and all works well then.
Is there a less hacky way? It's really weird that I can't tell GCC to prioritize its own libraries.
Also, is there some way to have CMake explain where different parts of a resulting command line came from?
I am a novice to cmake and boost so this question might be missing something obvious:
I am building a project with cmake on linux (ubuntu) and I am trying to use boost logging in that project. Here is what I do to generate the Makefile:
rm CMakeCache.txt
cmake ../ -DCMAKE_EXE_LINKER_FLAGS="-lboost_log -lboost_log_setup -lpthread -std=c++11" -DCMAKE_SHARED_LINKER_FLAGS="-lboost_log_setup -lboost_log -lpthread" -DCMAKE_MODULE_LINKER_FLAGS="-lboost_log_setup -lboost_log -lpthread" -DCMAKE_CXX_FLAGS="-DBOOST_LOG_DYN_LINK -std=c++11"
Compile goes through fine. (Some of these flags may be overkill -- I should only need the CMAKE_EXE_LINKER_FLAGS).
When I run the executable, I get the following unresolved reference:
-- ImportError: /home/mranga/gr-msod-sensor/gr-msod_sensor/build/lib/libgnuradio-msod_sensor.so: undefined symbol: _ZN5boost3log11v2_mt_posix3aux25unhandled_exception_countEv
What flags am I missing? My boost library is set up and LD_LIBRARY_PATH points to the right location.
When I manually built a test program using the same linker flags, it compiles and runs fine so boost is installed correctly. I hope I have not missed the obvious.
(Moved question from the GNU Radio mailing list -- sorry if you are reading this post for a second time).
I believe the order of libraries in the linker command line in -DCMAKE_EXE_LINKER_FLAGS is incorrect. boost_log_setup depends on boost_log, so boost_log_setup should go first.
You seem to be linking against the non-multithreaded version:
-lboost_log
but the run-time linker seems to explicitely look for the multithreaded variant (the Boost doc site on that):
_ZN5boost3log11v2_mt_posix3aux25unhandled_exception_countEv
^^
My guess hence is that you should try linking with
-lboost_log_mt
but the question whether that is right or not depends too much on your individual project to make it possible for me to clearly answer this.
I'm learning SDL through Lazy Foo's tutorial, but I can't proceed further as IMG_Load doesn't seem to work. I tried setting it up like he says, but it just doesn't work. I put all the include files into include folder, and all the lib files into the lib folder. What I found is that there were x86 and x64 folders in the lib folder. When I tried x64 (because I have a 64-bit system)it all worked fine, CodeBlocks even told me suggestions (like when I wrote "img" it showed up a suggestion "IMG_Load" (which means the library got initalized?)), but when I come to compiling my code, this happens: http://puu.sh/3Eqa5.png. When I try with the x86 version, exact same error.
I had a little search around the internet, and all I could find were a few threads, but most of them were abandoned. The closest I got to answering my problem was this: http://www.dreamincode.net/forums/topic/118299-sdl-image-error-sdl/ but the guy solved his problem by downloading a problem which Linux can use, not Windows.
}
I'm running Windows 7 64-bit, CodeBlocks 12.11, SDL 1.2.15 and SDL_Image 1.2.12.
I really don't know what the problem is!
You should go to the Compiler and Debugger settings again and under the Linker Settings tab paste:
-lSDL_image
In addition to the #Aleeee's answer, a command line solution is to add -lSDL2_image compiler flag (SDL2 is the up-to-date version by the time of this writing).
Compilation example:
gcc -o object_file_name source_file_name.c `sdl2-config --cflags --libs` -lSDL2_image
It turns out the SDL_Image library I was using was buggy. I don't know how that happened though. I just had to use a older version. Thanks to anyone who helped!
I am currently working on a simple data synchonizer in a mixture of Fortran and C/C++ by using OpenMPI libraries. The synchonizer compiles and links correctly, as far as I can see:
f95 -o fortran_mpi_test *.o -L/usr/lib/gcc/x86_64-redhat-linux/4.1.1/
-L/usr/lib64/openmpi/1.4-gcc/lib/ -lmpi -lmpi_cxx -lstdc++
But when I execute the resulting executable on the same machined I get an error stating that one of the shared libraries is not found. That is confirmed by ldd.
Nevertheless the missing library libmpi_cxx.so.0 is located in one of the specified folders.
Could anyone give me a hint what I could have done wrong?
Check your environment variables. If your LIBRARY_PATH, LD_LIBRARY_PATH or similar vars have gotten out of sync or set to silly values you might not be searching the same directories for static libraries as you do for dynamics.
Also check out the ld.so manpage
I am trying to run FFTW code in a mex file. This is strictly for the purpose of development and testing. After some googling, I see that others have tried to do something similar and have had related problems, but I have not found any solutions. When attempting to run the mex file, Matlab tells me:
??? Error using ==>
chirpTransform.mxCta Invalid MEX-file
'\removed\my\directory\+chirpTransform\mxCta.mexw32':
The specified procedure could not be
found.
.
I am using gnumex with MinGW to build the mex file because LCC seems to have some issues. I have tried using the 32 bit DLL from the FFTW site (http://www.fftw.org/install/windows.html). I have tried using the fftwf3.dll in the Matlab 2009b bin directory. I built the dll from source using Msys/MinGW. In all cases, the results are the same. In all cases I did the following to generate the lib file.
c:\gnumex\mexdlltool.exe -d
libfftw3f-3.def -D libfftw3f-3.dll -l
libfftw3f.lib --as C:\MinGW\bin\as.exe
I also tried using the visual studio lib.exe tool and experimented with various mexdlltool flags.
It appears that I can directly call functions in the fftwf3-3.dll using Matlab's loadlibrary functionality. Since the DLL appears not to be the problem, I tried building a static version of fftwf3 and linking it directly into the mex file. I got the same results! If I remove the FFTW code, the mex file runs fine. I have just about given up at this point, and I am tyring to come up with alternative methods of testing.
I've run into this issue with other mex functions. In my experience, it typically means that there is a dependency issue. Some dependency is not located.
Here is a link to TMW's documentation on this issue:
Invalid MEX-File Error
Give it a read, and then try using dependency walker to diagnose the problem.
It's been a long time, and my setup has changed, but this works for me now. I suspect hoogamaphone was right. I probably didn't have the fftw dll in the same directory as the mex dll (and it wasn't in my path). In fact, 64 bit Matlab 2016a still gives you a warning about not being able to find the mex file when, in fact, it's a dependency that's missing.
My current setup is using the Visual Studio 2013 C++ compiler by default. As mentioned on the fftw web site, you need to generate a lib file for linking. You can run the Visual Studio command prompt from a regular command prompt like so:
"%VS120COMNTOOLS%VsDevCmd.bat"
Then run the following in the directory with the def file.
lib /machine:x64 /def:libfftw3f-3.def
And compile.
mex mxCta.c cta.c -I../fftw -L../fftw -llibfftw3f-3.lib
Perhaps another possibility is that gnumex introduced some dependency into the mex dll. I no longer recall whether I had used gnumex successfully testing other code. When using cygwin, if you don't use the mingw compiler (x86_64-w64-mingw32-gcc), you'll end up with a dependency on the cygwin1.dll.
Finally, if you use more than one compiler, make sure all the compiler flags are the same (same function calling conventions, ABI, etc). Also, Mathworks has changed the mex build procedure. In a recent project, I copied mexconfig.xml to my local directory from
C:\Users\myuser\AppData\Roaming\MathWorks\MATLAB\R2016a\mex_C_win64.xml
and edited the compiler flags like so:
COMPFLAGS="/Zp8 /GR /W3 /EHs /nologo /MD /Gz /TC"
If you use a custom build file, use the -f option.
mex mxCustom.c custom.lib -f mexconfig.xml