(Crosspost from here, since nobody seems to have an idea)
Hello everyone,
I am trying to cross compile qt 4.8.3 from my linux for my windows. The final goal is to build a static qt, but independent of building static or not I always get the same error. Playing around with various flags didn't help either:
./.obj/release-shared/qtextcodec.o:qtextcodec.cpp:(.text+0x18dc): undefined reference to `QGb18030Codec::QGb18030Codec()'
./.obj/release-shared/qtextcodec.o:qtextcodec.cpp:(.text+0x18ef): undefined reference to `QGbkCodec::QGbkCodec()'
./.obj/release-shared/qtextcodec.o:qtextcodec.cpp:(.text+0x1902): undefined reference to `QGb2312Codec::QGb2312Codec()'
./.obj/release-shared/qtextcodec.o:qtextcodec.cpp:(.text+0x1915): undefined reference to `QEucJpCodec::QEucJpCodec()'
./.obj/release-shared/qtextcodec.o:qtextcodec.cpp:(.text+0x1928): undefined reference to `QJisCodec::QJisCodec()'
./.obj/release-shared/qtextcodec.o:qtextcodec.cpp:(.text+0x193b): undefined reference to `QSjisCodec::QSjisCodec()'
./.obj/release-shared/qtextcodec.o:qtextcodec.cpp:(.text+0x1956): undefined reference to `vtable for QEucKrCodec'
./.obj/release-shared/qtextcodec.o:qtextcodec.cpp:(.text+0x1971): undefined reference to `vtable for QCP949Codec'
./.obj/release-shared/qtextcodec.o:qtextcodec.cpp:(.text+0x198c): undefined reference to `vtable for QBig5Codec'
./.obj/release-shared/qtextcodec.o:qtextcodec.cpp:(.text+0x19a7): undefined reference to `vtable for QBig5hkscsCodec'
I'm using the default win32-g++ configuration file in combination with mingw.
I googled quite a bit around, but I have still no idea, where this comes from.. Maybe someone of you has the right hint for me ;-)
You could use MXE to build it. It's quite easy. You simply do:
make qt
It does pretty much everything automatically, including downloading sources, applying needed patches to enable cross compiling (which might be why manually cross compiling Qt on your own is failing), and building all dependencies. You can download MXE from: http://mxe.cc. Read the docs of course on how to cross compile software with it.
The gist of it is that instead of qmake you use i686-pc-mingw32-qmake (after you've changed your PATH to include the MXE directory, as per the docs.)
MXE builds everything as static libraries, so when you cross compile a program, you'll get a single .exe file with no depenendies on any DLLs.
Related
I'm building something using Cygwin 32 bit. It's quite large so it has a couple of header files defined in their own .cpp files. I'm even using a few c++ boost headers, linking them. I'm doing this on x64 Eclipse Luna. The project is comprised of a mix of C and C++ files. Every time I build the project I keep getting undefined references errors, for all functions in the header files, including those from boost, despite me having linked the boost libraries correctly. Unfortunately, I don't have enough reputation to attach a screenshot(doesn't make any sense). But below is a sample of the errors. I have even tried linking using option enable-stdcall-fixup to no avail.
./caches.o:caches.cpp:(.text+0x1957): undefined reference to `boost::filesystem::detail::directory_iterator_construct(boost::filesystem::directory_iterator&, boost::filesystem::path const&, boost::system::error_code*)'
./caches.o:caches.cpp:(.text$_ZNK5boost10filesystem16filesystem_error4whatEv[__ZNK5boost10filesystem16filesystem_error4whatEv]+0xa2): undefined reference to `boost::filesystem::path::codecvt()'
./fscore.o:fscore.cpp:(.text+0xa1): undefined reference to `btree_init()'
Please help.
Sincerely, batman
I'm trying to install a program (the Parallel Ice Sheet Model, or PISM) which uses MPI. I keep running into the errors
libpismutil.so: undefined reference to `ompi_mpi_cxx_op_intercept'
libpismutil.so: undefined reference to `MPI::Datatype::Free()'
libpismutil.so: undefined reference to `MPI::Comm::Comm()'
libpismutil.so: undefined reference to `MPI::Win::Free()'
when linking a CXX executable. I'm sort of stumped as to why this is occurring; the configuration for the program found where all of the MPI executables and libraries are located.
In another thread, someone suggested that this is due to different naming conventions when MPI is built with Fortran or C, but seeing as I have both mpicc.mpich2 and mpif90.mpich2 in my /usr/bin I would think this wouldn't be a problem.
After much consternation, I've found the culprit. The program I'm trying to install uses a library for scientific computation called PETSc; the standard install of PETSc doesn't generate the shared object files needed by PISM, you have to explicitly tell it to make them. Once this was done, PISM installed correctly.
Of course, I was unable to run it because of some other obscure error with openmpi, but that's a story for another thread.
I am trying to build a program that will hopefully create dynamic .pdf files. I have actually developed a similar project with PHP for web, but now I want to write it with C++.
This resulted me to rebuild those three libraries (zlib, libpng and libharu) more than time times for the last four days. I have read all the relevant entries in the web (including this stack overflow entry) I understood that my problem is that the compiler cannot find zlib (maybe I understood the problem wrongly)
I want to explain what I've done. Please note that I'm using Codeblocks IDE with GNU GCC C++ Compiler (MingGW) in Windows 7. First, I compiled zlib 1.2.7 and created my zlib.a static library file (I'm using static libraries). Secondly, I compiled libpng 1.5.13 and created my libpng.a. Thirdly, I compiled libharu (snapshot) and created my libharu.a static library file. Then I added those library files to my project. (I did everything explained in here). And at last, compiled my project.
Well, I shall say I did those all steps more than ten times, changing some small things, but everytime I am getting an error. I have even tried the official examples in libharu.org.
The most weird thing is that my error is NOT stable. Nearly everytime I got different errors! But mostly it was related with hpdf_streams.c.
My recent log file:
C:\Libs\libharu-201301131604\libharu.a(hpdf_streams.o):hpdf_streams.c:(.text+0xd4a): undefined reference to `deflateInit_'
C:\Libs\libharu-201301131604\libharu.a(hpdf_streams.o):hpdf_streams.c:(.text+0xdfa): undefined reference to `deflate'
C:\Libs\libharu-201301131604\libharu.a(hpdf_streams.o):hpdf_streams.c:(.text+0xe78): undefined reference to `deflateEnd'
C:\Libs\libharu-201301131604\libharu.a(hpdf_streams.o):hpdf_streams.c:(.text+0xee2): undefined reference to `deflate'
C:\Libs\libharu-201301131604\libharu.a(hpdf_streams.o):hpdf_streams.c:(.text+0xf7e): undefined reference to `deflateEnd'
C:\Libs\libharu-201301131604\libharu.a(hpdf_streams.o):hpdf_streams.c:(.text+0xfb7): undefined reference to `deflateEnd'
C:\Libs\libharu-201301131604\libharu.a(hpdf_streams.o):hpdf_streams.c:(.text+0xff1): undefined reference to `deflateEnd'
We just had this issue. You need to recompile zlib with WIN_API off. Or use the dll's and not the static library.
When I try to compile a random project in Code:Blocks, the Cygwin Compiler throws an undefined reference error about own library files:
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../libcygwin.a(_cygwin_crt0_common.o):_cygwin_crt0_common.cc:(.data+0x0):
undefined reference to `___real__Znwj'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../libcygwin.a(_cygwin_crt0_common.o):_cygwin_crt0_common.cc:(.data+0x8):
undefined reference to `___real__ZdlPv'
I am linking the netlink library as well as the WS2_32.lib
Is that a compiler issue?
Other hint, it comes from _cygwin_crt0_common.cc. So there is obviously central something missing. You are using Cygwin version of gcc, right? Have your tried -lcygwin? You could also try -mno-cygwin.
My advice is normally to use vanilla MinGW, creates clean windows binaries (at the loss of POSIX features)..
Recently I have asked a question about what I should use to create self-contained executables that would be deployed under a number of Linux distribution. I got very scared at first, but after reading about C++ a little, I managed to get the first version of my executable going.
After a day full of joy, I just hit the wall again with another dilemma. The resulting executable must be installed in a number of Linux distributions (Slackware, Arch, Ubuntu, Debian, CentOS and a few more), and I am completely clueless on how to achieve it. All I know CentOS and Debian-based OSes has package managers, like apt or yum, but I am not sure those apply to my case.
The code I wrote depends on a couple of libraries (more specifically RudeSocket and yaml-cpp. I have been told that I would be able to compile the executable and link it dynamically, so I just needed to distribute the executable.
It happens that I could not find the .a file for the yaml-cpp library (just for RudeSocket). And here's my problem so far:
At first, I went with dynamic linking but (obviously) when I copied the executable to another box:
$ ./main
./main: error while loading shared libraries: libyaml-cpp.so.0.2: cannot open shared object file: No such file or directory
When trying to compile it statically, I get an error too (because I don't have the yaml-cpp .a file as I mentioned):
$ g++ main.cpp parse.cpp parse.h rudesocket-1.3.0/.libs/librudesocket.a -o main -static -L/usr/local/librudesocket-1.3.0/.libs/librudesocket.a(socket_connect_normal.o): In function `rude::sckt::Socket_Connect_Normal::simpleConnect(int&, char const*, int)':
/root/webbyget/sockets/rudesocket-1.3.0/src/socket_connect_normal.cpp:250: warning: Using 'gethostbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/tmp/cc3cEVK1.o: In function `operator>>(YAML::Node const&, Job&)':
parse.cpp:(.text+0x1a83): undefined reference to `YAML::Node::size() const'
/tmp/cc3cEVK1.o: In function `handle_job(rude::Socket, char const*)':
parse.cpp:(.text+0x1b79): undefined reference to `YAML::Parser::Parser(std::basic_istream<char, std::char_traits<char> >&)'
parse.cpp:(.text+0x1bfd): undefined reference to `YAML::Node::Node()'
parse.cpp:(.text+0x1c10): undefined reference to `YAML::Parser::GetNextDocument(YAML::Node&)'
parse.cpp:(.text+0x1dc6): undefined reference to `YAML::Node::size() const'
parse.cpp:(.text+0x1dee): undefined reference to `YAML::Node::~Node()'
parse.cpp:(.text+0x1e18): undefined reference to `YAML::Node::~Node()'
parse.cpp:(.text+0x1e37): undefined reference to `YAML::Parser::~Parser()'
parse.cpp:(.text+0x1e61): undefined reference to `YAML::Parser::~Parser()'
(...)
It's pretty obvious to me that g++ cannot compile it statically without telling it where to find the classes for yaml-cpp.
It is very important that the installation should happen without human interaction, in an automated fashion.
So my question is really twofold:
how can I distribute this compiled program in the least complex way targeting all those distributions?
is there any de facto standard solution for this kind of problem?
Thank you in advance,
Felipe.
You might give this technique a try.
There are many de-facto standards, but none of them are standardized. :( If you want to distribute a compiled binary, you will probably want to make a package for each platform you want to target. Generating an rpm and a deb will probably get you 90% of the way. If you want to automate the build process, autoconf/automake is still (probably) the best way to go.
Maybe The best solution for you is to use CMake.
CMake is cross-platform, open-source build system. It is a family of tools designed to build, test and package software. For Packaging, Mgb is right, CMake can easily be coupled with CPack.
KDE is using this solution and its a very good alternative to automake/autoconf.
If you use the platforms package manager (.rpm or .deb) the system will check for the correct version of the shared library for you and download it if it is needed.
CPack is probably the easiest package generator