static building with 3rd party library
-
Hi all -
I posted about this awhile back, and had it working, but upon updating to 5.14.1 and doing a rebuild, the problem has recurred.
I need to build a static, standalone app that uses a 3rd-party library (expat). I've added this to my .pro file:
expatInstallsDebug.files = "C:/Program Files (x86)/Expat 2.2.5/Bin/libexpat.dll" expatInstallsDebug.path = $$OUT_PWD expatInstallsRelease.files = "C:/Program Files (x86)/Expat 2.2.5/Bin/libexpat.lib" expatInstallsRelease.path = $$OUT_PWD INSTALLS += expatInstallsDebug expatInstallsReleaseAnd added a "make install" step to my build. Now my dynamic build works. But when I build static, and remove the .exe from its directory, I get an error:
The code execution cannot proceed because libexpat.dll was not found. Reinstalling the program may fix this problem.
It appears that I need to add some logic in my .pro file that is debug/release specific. Can someone suggest how I might best accomplish this?
Thanks...
@mzimmers said in static building with 3rd party library:
It appears that I need to add some logic in my .pro file that is debug/release specific. Can someone suggest how I might best accomplish this?
CONFIG(static, shared|static): // Stuff for static CONFIG(debug, debug|release): // Stuff for debug CONFIG(release, debug|release): // Stuff for releaseRead and abide by the Qt Code of Conduct
-
@mzimmers said in static building with 3rd party library:
It appears that I need to add some logic in my .pro file that is debug/release specific. Can someone suggest how I might best accomplish this?
CONFIG(static, shared|static): // Stuff for static CONFIG(debug, debug|release): // Stuff for debug CONFIG(release, debug|release): // Stuff for release@kshegunov thanks. I've read the documentation about the CONFIG variable; seems kind of like a Swiss army knife -- lots of uses. I still don't understand the syntax (in terms of how to fully form the CONFIG statement) but I'm guessing I need to use the "link_prl" option somehow?
I'm starting to remember a previous go with this...I think you were one of the people who helped me. I seem to recall problems with using the .lib directly, and needing the .dll. You provided a rather elaborate solution, the details of which I can't recall nor find by searching this forum. Does this ring a bell with you?
-
@kshegunov thanks. I've read the documentation about the CONFIG variable; seems kind of like a Swiss army knife -- lots of uses. I still don't understand the syntax (in terms of how to fully form the CONFIG statement) but I'm guessing I need to use the "link_prl" option somehow?
I'm starting to remember a previous go with this...I think you were one of the people who helped me. I seem to recall problems with using the .lib directly, and needing the .dll. You provided a rather elaborate solution, the details of which I can't recall nor find by searching this forum. Does this ring a bell with you?
@mzimmers said in static building with 3rd party library:
I've read the documentation about the CONFIG variable; seems kind of like a Swiss army knife -- lots of uses.
Yes, it has.
I still don't understand the syntax (in terms of how to fully form the CONFIG statement)
It's a sort of string matching machinery.
CONFIG(debug, debug|release): # evaluates to true if debug is present in CONFIG out of the possible `debug` and `release` valuesI'm starting to remember a previous go with this...I think you were one of the people who helped me. I seem to recall problems with using the .lib directly, and needing the .dll. You provided a rather elaborate solution, the details of which I can't recall nor find by searching this forum. Does this ring a bell with you?
Usually it's the other way around, but it may be and I've just forgotten. I have no recollection of it, sorry.
-
Found it!
I'm using MinGW (not MSVC). Are the C-runtime libraries available in static form, or do I need to build them?
Perhaps I should stop focusing on building the standalone app, and instead just supplying a .msi style installation?
-
Hi,
IIRC, you would also have to rebuild Qt itself to use the static runtime (at least that's what you have to do with Visual Studio). You have four option static/shared using static/shared runtime. I am not sure MinGW provides the equivalent for the runtime part.
Interested in AI ? www.idiap.ch
Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct -
Hi,
IIRC, you would also have to rebuild Qt itself to use the static runtime (at least that's what you have to do with Visual Studio). You have four option static/shared using static/shared runtime. I am not sure MinGW provides the equivalent for the runtime part.
-
Hi,
IIRC, you would also have to rebuild Qt itself to use the static runtime (at least that's what you have to do with Visual Studio). You have four option static/shared using static/shared runtime. I am not sure MinGW provides the equivalent for the runtime part.
@SGaist said in static building with 3rd party library:
I am not sure MinGW provides the equivalent for the runtime part.
No not that I know of. MinGW uses a thin wrapper around the MS C runtime, but I don't believe you can instruct it to link the msvcrt statically. I think the best that can be accomplished is to force it to not depend on its wrapper dynamically.
@mzimmers said in static building with 3rd party library:
Are the C-runtime libraries available in static form, or do I need to build them?
If you mean the microsoft's runtime, yes, they're available. But I don't think there's a straightforward (or any) way to use them with mingw.
Perhaps I should stop focusing on building the standalone app, and instead just supplying a .msi style installation?
That's what'd be my preferred method, honestly. Static binaries have some advantages (and disadvantages), but my personal preference is to just deploy with dynamic libraries.
I use -static -static-runtime in my configure command; is that what you're talking about?
Yes, that's the two relevant flags.
Read and abide by the Qt Code of Conduct
-
@SGaist said in static building with 3rd party library:
I am not sure MinGW provides the equivalent for the runtime part.
No not that I know of. MinGW uses a thin wrapper around the MS C runtime, but I don't believe you can instruct it to link the msvcrt statically. I think the best that can be accomplished is to force it to not depend on its wrapper dynamically.
@mzimmers said in static building with 3rd party library:
Are the C-runtime libraries available in static form, or do I need to build them?
If you mean the microsoft's runtime, yes, they're available. But I don't think there's a straightforward (or any) way to use them with mingw.
Perhaps I should stop focusing on building the standalone app, and instead just supplying a .msi style installation?
That's what'd be my preferred method, honestly. Static binaries have some advantages (and disadvantages), but my personal preference is to just deploy with dynamic libraries.
I use -static -static-runtime in my configure command; is that what you're talking about?
Yes, that's the two relevant flags.
@kshegunov yeah, I suppose you're right. I have one customer who likes things as simple as possible, and to him, simple equates to a single .exe file that he can move anywhere. He's a HW engineer, incipiently mistrustful of SW, and more so when it gets what he perceives as complicated. But...maybe it's time I reminded him that Clinton's out of office, and times have changed.
I'm really close to getting this to work, though...the only file that my .exe needs is the libexpat.dll. If I move that file with my .exe it runs.
-
@kshegunov yeah, I suppose you're right. I have one customer who likes things as simple as possible, and to him, simple equates to a single .exe file that he can move anywhere. He's a HW engineer, incipiently mistrustful of SW, and more so when it gets what he perceives as complicated. But...maybe it's time I reminded him that Clinton's out of office, and times have changed.
I'm really close to getting this to work, though...the only file that my .exe needs is the libexpat.dll. If I move that file with my .exe it runs.
@mzimmers said in static building with 3rd party library:
@kshegunov yeah, I suppose you're right. I have one customer who likes things as simple as possible, and to him, simple equates to a single .exe file that he can move anywhere. He's a HW engineer, incipiently mistrustful of SW, and more so when it gets what he perceives as complicated. But...maybe it's time I reminded him that Clinton's out of office, and times have changed.
Comes with the territory, I guess. As a physicist, I don't put much faith in engineers either ... although I must admit my reservations are mostly misguided ...
I'm really close to getting this to work, though...the only file that my .exe needs is the libexpat.dll. If I move that file with my .exe it runs.
Hm, is that a Qt dependency, or one of your own? I don't recall deploying it ...
