I'm having a problem trying to cross-compile a wxWidgets sample program.
The host is a PC running Debian (a VM if it matters), and the target is a BeagleBone Black (BBB) also running Debian.
As a background note, I'm a C/C++ programmer, but strictly in the embedded and Windows world. I know just enough about Linux to be able to break it.
I've successfully cross-compiled a simple C++ program, and it runs fine on the BBB. I used the tutorial from Derek Molloy to get Eclipse installed and cross-compiling:
https://www.youtube.com/watch?v=hzZHcH5quow
Next, I downloaded wxWidgets and compiled it on the BBB (not on the PC) into static libraries. Here's the config I used:
../configure --enable-debug --enable-debug_info --disable-shared --enable-stl --enable-sockets --enable-gif --enable-pcx --with-libpng --with-libjpeg
It compiled fine. I then built a bunch of the demos and samples and they all compiled and ran fine on the BBB.
Next I wanted to be able to cross-compile so I could use some decent development tools.
I copied all the wxWidgets libraries over to the PC, then I also copied all the include directories I would need (GTK, cairo, pango, glib...) and their libraries (from the BBB to the PC).
After a lot of trial and error, I finally got it all to compile and link. Almost.
The linker is giving the following errors (5 of them, all very similar):
`.LTHUNK0' referenced in section
`.text._ZN17wxWindowWithItemsI9wxControl15wxItemContainerED1Ev[_ZN17wxWindowWithItemsI9wxControl15wxItemContainerED1Ev]'
of
/home/dave/BeagleBoneResources/lib/wx/libwx_gtk2u_core-3.0.a(corelib_choiccmn.o):
defined in discarded section
`.text._ZN17wxWindowWithItemsI9wxControl15wxItemContainerED2Ev[_ZN17wxWindowWithItemsI9wxControl15wxItemContainerED5Ev]'
of
/home/dave/BeagleBoneResources/lib/wx/libwx_gtk2u_core-3.0.a(corelib_choiccmn.o)
I see it's referencing libwx_gtk2u_core-3.0.a, which is one of the wxWidgets libraries I built on the BBB.
Can anyone tell me how to fix this? I sure hope I don't have to rebuild all the dependencies with the cross compiler, there's a LOT of them, and I wouldn't even know where to start.
Related
I am running a project which use SFML and who works perfectly fine on Linux.
I am now Compiling my project on Window and it works.
I am Using Cmake actually.
The thing is when I start my SFML APPLICATION it just doesn't run.
I mean when I start it, The main's first line of code isn't executed.
The error seems to be due to Shared Libraries Linking but I can't figure Why ?
I've Included the SFML dlls in the binary directory, so I didn't got (explicitly at least) errors about shared libraries. (When running Through a terminal)
I do not Compile my program with static SFML Linking otherwise I wouldn't have this question
I've also compiled SFML myself (and installed it ofc) and use the same Compiler ("-G"MinGW Makefiles") to build my SFML Application.
I've seen someone who got a driver's update problem, but I've already tried the solution
The error code is:
when running through a Git-bash terminal. (No explicit Error)
echo $? -> 127
(so -1 at runtime)
And when Running through CLion:
Process finished with exit code -1073741792 (0xC0000020)
If someone can help me it would be great!
EDIT:
When using dependency walker (and select SFML dlls)
I got an error too This files is not a valid 32-bit or 64-bit Windows Module
But I do not understand why since I've compile SFML myself
I have copied my qt C++ program into another computer running the same Ubuntu version but it did not work. The terminal told that it can't find the:
libQt5PrintSupport.so.5
libQt5Core.so.5
libQt5Widgets.so.5
libQt5Gui.so.5
I then installed the qt essentials and qt base and afterwords verified that these libraries were installed but still got the same errors.
Then I tried to install the Qt creator itself but it gave me errors considering pre-build C++ files like function multiple definitions (of course no such errors on my computer)
While on my computer I even didn't have to use the LD_LIBRARY_PATH
Please help
Solve my problem:
The thing is that all Qt programs are hardware dependent and not software dependent like CODE::BLOCKS (thus will need dependencies externally)
What you have to do is install the Qt Creator and recompile your program, but wait it wont be that easy what you have to do is in the project tab disable the output folder ao that the program will be executed internally then enable the output folder and say yes so that you will rewrite your output folder
I'm building a QT application on Ubuntu that works pretty good. Now I have to deploy it on Windows, so I installed MXE in order to cross compile my sources.
MXE build
git clone https://github.com/mxe/mxe.git
cd mxe
# I need posix threads, that why I build static.posix target
make MXE_TARGETS='i686-w64-mingw32.static.posix' qtbase libxml2
I use a personal library (that uses cmake) and a client/server code for my QT code, that I compiled with MXE and it did not give any error (I worked hard to fix them...). Then, the compilation for the QT reaches the end without any error.
Whenever I try to execute the program (with wine on Ubuntu or on Windows) it does not work. wine freezes and Windows shows me a Runtime Error.
I also tried to use the windeployqt.exe using wine on my executable, hopping it will give me the missing dlls, but it tells me :
Z:\path\release\Executable.exe 32 bit, release executable
Z:\path\release\Executable.exe does not seem to be a Qt executable.
I really have no idea on what is broken. Am I forgetting to put dlls, or is my compilation failing silently ? Does anyone knows or have ideas on how to deal with that case ?
EDIT
Apparently I compile correctly my program, the error seems to come from GetAdapterAdresse when using Windows. The problem is not coming from MXE at all (I'm glad I made it work though).
I'll have to have a look on this function, but anyone knows how to make gdb work with MXE ? When I ran make gdb, it has built something, but I can't figure out where is the program.
I set up OpenCV with Code::Blocks as per this tutorial: http://kevinhughes.ca/tutorials/opencv-install-on-windows-with-codeblocks-and-mingw/.
I've got as far as building the test program at the end successfully, but when I try to run it I get the following error: "The application was unable to start correctly (0xc00000be). Click OK to close the application."
The one thing that is certainly different from the tutorial for me is that I'm working with OpenCV 3.0.0, Code::Blocks 13.12 and the latest version of mingw (number not obvious from their website or the installer).
I found that other people had had this problem in the past, e.g. The application was unable to start correctly (0xc00000be)
However, it has been a long time since that thread was active, I'm working with newer versions of the software and, most importantly, the answer given there didn't help (I compiled openCV with the same mingw that I'm using with Code::Blocks), so I thought this question would be worth asking (sorry if it's not, I'm rather new to this).
Could anybody suggest a fix that might get rid of this error?
A few other things to note:
I didn't download the Code::Blocks that came with mingw as I was advised against it, I got them separately as per the tutorial
I have installed OpenCV and Code::Blocks on my E: drive, though mingw is still on my C:.
I have added both mingw and OpenCV to my PATH variable, and mingw to my Path variable
I have linked the libraries in both the main compiler settings for Code::Blocks and the Build Options of my project.
I'm working from a 64-bit Windows 7 Laptop, but I have done everything 32-bit style as advised in the tutorial.
Thanks in advance!
So, one solution I've found to this problem is to copy all the .dll files from "...\opencv\build\x86\mingw\bin" to the project file (build directory).
Having done that, the project will run fine. This still doesn't (directly) explain why it wont run without those files (at least, several sources including the tutorial imply it should), and so isn't really optimal. I will continue to look for a solution for this so I don't have to clutter every opencv project I make with the .dlls.
However, for anyone simply wanting to get stuck into coding who is having this problem, I recommend that solution.
I try to get wxWidgets installed on a Windows7 x64 Machine but wxWidgets Installation doesn't even work, I cannot get a Hello World App running.
I found out there are several ways to get the library installed and I tried some of them (with Cygwin and the included mingw64 compiler, with mingw64 using diffrent settings), all the time I get Errors while building the library. Could somebody point me out what's wrong with my current setup (which was also my first try) or show another solution?
First I installed mingw64 with the online installer to c:/mingw64. I tried some different setups concerning Version and Threads, but ended up with 4.9.2, x86_64, posix Threads, sjlj Exceptions.
Then I downloaded MYSYS from sourceforge.net and extracted it to C:/mysys.
Then I created a folder C:/wxWidgets and mounted it as /wxWidgets, downloaded the wxWidgets 3.0.2 source and put in into my mysys-home folder.
From /wxWidgets I executed: /home/Martin/wxWidgets-3.0.2/configure --host=x86_64-w64-mingw32 --disable-shared --enable-monolithic
The configure did his job without errors though some libraries couldn't be found and built-in libraries were taken instead (jpeg, png, regex, tiff, expat).
Then I executed make and it ran for some minutes and suddenly crashed. The only output was make: *** [monolib_any.o] Error 1
The last executed command was /wxWidgets/bk-make-pch ./.pch/wxprec_monolib -D__WXMSW__ ...
Right before, there is an note concerning POSIX paths: "CYGWIN environment variable option "nodosfilewarning" turns off this warning...
All the other tries ended up like this one, make suddenly hung up. Any help appreciated.
If the make/compile process really dies without any other error messages, the most likely explanations are that either it runs out of memory (but even then normally there would be some error message) or some hardware problem, it's really not supposed to do this on a working machine.
So my advice would be to run some hardware diagnostics. If this shows nothing, run make -n and execute the command used to compile any.cpp by hand by copy and pasting it.