I know, I dug the whole internet to find out what the problem is and nothing has been helpful so far.
I am on Windows 7, using:
Qt 4.8.3: https://download.qt.io/archive/qt/4.8/4.8.3/qt-win-opensource-4.8.3-mingw.exe
MinGW32 4.4.0: http://nosymbolfound.blogspot.com/2012/12/since-until-now-qt-under-windows-is.html
I can compile any Qt demo example with Qt Creator, so I believe my system is working fine.
When trying to compile the program I ran into the well known issue:
g++ -enable-auto-import -o libqlcengine.a object_script.libqlcengine.Debug -L".\lib" -L"c:\Qt\4.8.3\lib" -lwinmm -L../../hotplugmonitor/src -lhotplugmonitor -lQtScriptd4 -lQtXmld4 -lQtGuid4 -lQtCored4
c:/mingw/bin/../lib/gcc/mingw32/4.4.0/../../../libmingw32.a(main.o):main.c:(.text+0x104): undefined reference to `WinMain#16'
(object_script.libqlcengine.Debug is a pretty long list of .o files)
Now, at that point of build it's trying to link a static .a library, so I see no reason for MinGW to look for WinMain. I did grep 'WinMain' and found no result on the entire source tree.
If you want to checkout the original sources:
svn co https://qlc.svn.sourceforge.net/svnroot/qlc qlc
Or my forked version:
git clone git://git.code.sf.net/p/qlcplus/code qlcplus-code
They have the same result.
Guys, what am I missing here ? I tried a whole bunch of C flags (-mwindows -lmingw32 -DQT_NEEDS_MAIN -lqtmain) but none worked.
Any magic please ?
P.S. Of course I can build on Linux either i386/amd64
SOLVED:
I just needed to add the following line to the .pro files where libraries were created:
win32:QMAKE_LFLAGS += -shared
[SOLVED]
I just figured out I needed to add the following line to the .pro files where libraries were created:
win32:QMAKE_LFLAGS += -shared
Related
I have this strange issue where creating / using a static library works in my Ubuntu VM but not on macOS:
ld: warning: ignoring file ./dist/libXXXX.a, building for macOS-x86_64 but attempting to link with file built for macOS-x86_64
Command to create the static library is:
ar rcs libtest.a obj1.o obj2.o ...
Compiler invocation:
gcc -g -Wall -Wextra main.c -L./dist -lXXXX -o main
Searching on google didn't yield any usable results except for this (maybe) related question on SO:
Possible related question
I realize this is an old post and you found your fix, but let me post this here for anyone else who runs into this problem for whom these answers don't provide a solution.
You might be using two different toolchains unknowingly, one from Apple (installed via Xcode) and one from GNU (installed via Home-brew or MacPorts). If you type ranlib --version and see version info showing that ranlib is GNU, this is likely the case.
Make sure that /usr/bin comes in your $PATH before /usr/local/bin and /opt/local/bin. When you run which -a ranlib, the first result in the list should be /usr/bin/ranlib. Same for which -a ar-- the first result should be /usr/bin/ar. If it is not so, you need to fix your $PATH.
Once you fix your path and clean your project, try building again and things should work.
The issue was solved when I directly put those object files rather than gathering them into a static library, i.e.,
gcc -g -Wall -Wextra main.c obj1.o obj2.o -o main
After that, I got many warnings like ld: warning: object file (obj1.o) was built for newer macOS version (11.0) than being linked (10.14), but it is a warning, and the object is linked, so the problem is solved.
The root cause is that some library passes -mmacosx-version-min=10.14 to gcc, so the object file is built for 10.14, but my macos is now 11.0.
If you want to make things work, try directly using object files rather than creating a static library.
If you want to resolve all the warnings, find ``-mmacosx-version-min` and comment it.
After looking at my script that automatically creates the static library I've found the culprit:
For some reason my tool created object files for header files (resulting in files like header.h.o).
Removing those fixed the issue.
I got a pretty simple project that uses Qt as well as FFmpeg that i developed under linux.
Now I'am having trouble cross compiling said project with MXE to use it on a windows machine.
Under linux everything i had to do was adding
LIBS += -lavcodec -lavformat -lswscale -lavutil
to Qt's .pro file and wrap the includes for FFmpeg in an "extern "C"" block and it compiles just fine.
Now for MXE i just cloned the git repo and used
make MXE_TARGETS='x86_64-w64-mingw32.static' qt5 ffmpeg
As the MXE doc states i set the PATH variable and used
qmake && make
But i get a lot of undefined reference errors regarding libavformat.
Can anybody tell me what i am doing wrong here? I'm kinda lost.
Okay so I got this working.
The mxe version of gcc requires you to include the library multiple times if it is referenced by a library after it in the list of libraries to link.
Add -lavformat to the end of the LIBS line.
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
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.
Build messages:
ld.exe cannot find -lSDLmain
ld.exe cannot find -lSDL
Build log:
c:/program files
(x86)/codeblocks/mingw/bin/../lib/gcc/mingw32/4.7.1/../../../../mingw32/bin/ld.exe:
cannot find -lSDLmain
c:/program files
(x86)/codeblocks/mingw/bin/../lib/gcc/mingw32/4.7.1/../../../../mingw32/bin/ld.exe:
cannot find -lSDL
Please help.
Its not letting me run any of my previous or new projects.(All console applications/projects)
I have checked
settings - global variables
the include and lib paths are correct as well as the base directory.
I recently tried to setup SDL2 but then I uninstalled Code::blocks completely.
Why is it trying to find -lSDLmain and -lSDL?
Also tried reinstalling code::blocks and the Rebuild other than just Build, still
does not work.
I checked this post: Cannot find -lSDLmain and -lSDL when compiling simple SDL program with g++
but the answer talks about letting your MinGW know where your SDL libraries are.
But I'm not even working with SDL.
Using GNU GCC compiler.