Planned maintenance has been done but it did not solve the problem. So work will continue on this and a new time for trying updates will be announced asap.
Library ABI compatibility
can anyone give me the picture on how to ensure qt picks up the right flags when I need to link a non-qt linux makefile project against a qt compiled lib.
Hi and welcome to devnet,
What kind of ABI to you have in mind ?
Pppp last edited by
Both the project and library are C++, so name-mangling besides compiler flags affecting e.g. struct alignment etc. are at issue.
Then it's up to you to ensure you are using the right stuff.
If you are using your distribution provided Qt and development libraries, you won't have any problem. If using custom built libraries, then you should ensure that everything is using the same flags correctly.
The project using the custom qt lib seems to also compile qmake itself. This looks a bit circumvent to me - is this really necessary or can you e.g. take the flags and just generate a .pro file?
Your description is a bit vague, can you get more specific?
You only need to compile qmake yourself if you build Qt from source code, e.g. if you cross compile for an embedded system. Otherwise using the prebuild binaries is just fine.
And you don't even need QMake to build a Qt-based program or library; Qbs and CMake are used often for this task also. I've even seen projects with handcrafted Makefiles.
Sorry, I didn't mention the project is cross compile, targeting embedded.
So I understand it's usual to compile the target-specific cross-compiler on the host platform, but is that really necessary for the makemake (qmake, not the dwarf planet) also?
What are you using for cross-compilation ?
It sounds strange that you have to re-build Qt each time you want to build your project.
So if I got that right, you just configure and manually run the same qmake binary to output for different platforms and then use the generated makefile in the parent makefile project or optionally one step earlier call qmake from the script (but generally not still one step earlier and...)?