Solved Building a standalone executable (Windows)
-
Building expat was easy. There was even a static build in the .sln file.
The resulting file is called libexpatMT.lib. I put this in my .pro file:
INCLUDEPATH += "C:/Users/mzimmers/Desktop/libexpat-R_2_2_7/libexpat-R_2_2_7/expat/lib" LIBS += libexpatMT.lib
And I'm getting a build error:
:-1: error: cannot find -lexpatMT.lib
Is this due to some confusion between Linux and Windows syntax for specifying a library?
EDIT:
I got rid of this error by supplying an absolute pathname for the library:INCLUDEPATH += "C:/Users/MZimmers/apps_desktop/libs" win32:LIBS += "C:/Users/MZimmers/apps_desktop/Qt_apps/wb_utility/libexpatMT.lib"
Now, however, I'm getting several instances of this error:
C:\Users\MZimmers\apps_desktop\Qt_apps\wb_utility\win32\tmp\Release_static\xmlparse.obj):-1: error: undefined reference to `@__security_check_cookie@4'
Any ideas on what I did to incur this?
-
You link the same way to static files:
-LC:/path/to/static/lib -lname_of_lib
Does that library have any dependency ?
-
@sgaist yes, but they all appear to be header files (at least, according to VS). It seems odd that the static build of the expat library would succeed, but that such an error would surface when trying to build my app.
EDIT:
BTW, the doc is a little confusing:
https://doc.qt.io/qt-5/qmake-variable-reference.html#libs
The textual explanation acknowledges what you say about pathnames, but the examples sort of suggest otherwise.EDIT again:
I just had an idea that this is related to some 32-bit/64-bit incompatibility. When I built my static version, I made it 32-bit, because I was trying to use the pre-built expat libraries. I think I now have to create a 64-bit static library. Stand by...
-
I now have a Qt static library (man that takes a long time to build), as well as a static Expat library, included in my project file like so:
LIBS += "C:/Users/MZimmers/apps_desktop/libs/libexpat-R_2_2_7/libexpat-R_2_2_7/expat/win32/bin/Release/expat_static.lib"
(I changed the default name of the expat library to eliminate some spurious but annoying VS warnings.)
When I attempt to build, I get errors indicating that the build isn't "seeing" the library (or at least not its contents):
So, what might I be doing wrong? I'm almost positive the "undefined" functions are indeed in the library. Thanks...
-
@mzimmers said in Building a standalone executable (Windows):
try:
LIBS += -l"C:/Users/MZimmers/apps_desktop/libs/libexpat-R_2_2_7/libexpat-R_2_2_7/expat/win32/bin/Release/expat_static.lib"
That's a lower-case ell in front of the library path/name
-
@mranger90 yeah, I already tried that...despite what the QMake page says, Qt doesn't seem to like the Linux format of specifying libraries:
:-1: error: cannot find -lC:/Users/MZimmers/apps_desktop/libs/libexpat-R_2_2_7/libexpat-R_2_2_7/expat/win32/bin/Release/expat_static.lib
Trying this, though, wasn't without value, as it indicates that I am indeed including the library in my build.
I wonder if this is some weird problem with name decoration...?
-
@mzimmers
I;m totally jumping in here, but I don't think you want the leading-l
under Windows, only the path.... -
Did you try:
LIBS += -L"C:/Users/MZimmers/apps_desktop/libs/libexpat-R_2_2_7/libexpat-R_2_2_7/expat/win32/bin/Release" -l expat_static
to split the search path and library name into separate directives ?
-
@jonb according to the docs, it should work (at least that's how I interpret it), but it sure doesn't seem to.
mranger: I think using the "normal" win32 format is working for me; I used it with my former version of Expat. I believe the problem lies elsewhere -- perhaps I didn't build the library correctly, though it is distributed as a near-turnkey VS solution.
-
@mzimmers
That docs page is the one I looked at. The examples forwin32:LIBS
do not have the leading-l
. The error messagecannot find -lC:/Users/MZimmers/apps_desktop/libs/libexpat-R_2_2_7/libexpat-R_2_2_7/expat/win32/bin/Release/expat_static.lib
shows it is looking for a filepath
-lC...
. Just a guess. -
@jonb the examples don't use the -L/-l, but the text suggests (to me, anyway) that they should work:
If you use the Unix -l (library) and -L (library path) flags, qmake handles the libraries correctly on Windows (that is, passes the full path of the library to the linker).
Anyway, it doesn't really matter, because I'm using this, and it works:
LIBS += "C:/Users/MZimmers/apps_desktop/libs/libexpat-R_2_2_7/libexpat-R_2_2_7/expat/win32/bin/Release/expat_static.lib"
At least it worked with the pre-built version 2.2.5; I still don't know what's going wrong here.
-
If you use the Unix -l (library) and -L (library path) flags, qmake handles the libraries correctly on Windows (that is, passes the full path of the library to the linker).
You're right, I missed that. Note it also says:
The library must exist for qmake to find the directory where a -l lib is located.
which sounds like just what that error message is indicating is happening (i.e. failing to find the library)?
I did say I was jumping in! What you have on your
LIBS +=
line looks to me as though it should work. -
@jonb I think if it couldn't find the library, I'd get a different error message. Somehow, I've screwed up the build of the lib...no idea how, but I might just start from scratch. I'll report back when I have something...
-
Well, this continues to get more interesting: I edited my project file, right-clicked and started the Add Library wizard. When I was finished, I had some stuff added that looked like this:
win32: LIBS += -L$$PWD/../../libs/libexpat-R_2_2_7/expat/win32/bin/Release/ -llibexpatMT INCLUDEPATH += $$PWD/../../libs/libexpat-R_2_2_7/expat/win32/bin/Release DEPENDPATH += $$PWD/../../libs/libexpat-R_2_2_7/expat/win32/bin/Release win32:!win32-g++: PRE_TARGETDEPS += $$PWD/../../libs/libexpat-R_2_2_7/expat/win32/bin/Release/libexpatMT.lib else:win32-g++: PRE_TARGETDEPS += $$PWD/../../libs/libexpat-R_2_2_7/expat/win32/bin/Release/liblibexpatMT.a
I had to comment out the else, as it (understandably) didn't know what to do with an .a file. I got an error message to the effect that it was skipping over my "incompatible" library in its search for -llibexpatMT. I realized that when I rebuilt the Expat library from scratch, I didn't specify a 64-bit platform. (I guess this was Creator's way of telling me this.)
So, I fixed that, rebuilt and now I get THESE errors:
I have absolutely no idea what all that nonsense is...anyone have a clue?Thanks...
-
Found the problem...turns out those symbols are looked for when this compiler switch is enabled, which it was in the VS project. I turned it off, and now the project builds...and runs when removed from the build directory, so I believe I have my long-coveted standalone image.
For those following along at home, I think you can ignore most of the above persiflage regarding the syntax for Windows libraries. What matters is that everything is of the same architecture: your application, your version of Qt, and any 3rd-party libraries you may use.
Thanks to all who looked at this.
-
persiflage
Incredible! I consider myself to have a good command of the English language, and I have never heard of that word! Nor come across it in day-to-day typical conversation. Last used by Shakespeare?? :)
-
@jonb said in Building a standalone executable (Windows):
persiflage
-
@sgaist
Indeed, and for my sins I studied 18th century French literature (Racine, Moliere anyone?)!But who the heck uses an 18th century French word in the middle of a tech post on an (English) Qt forum? ;-)
-
@jonb heh...well, I may not be much of a programmer, but I do know a lot of words, and I enjoy using them.
A couple of weeks ago, I was playing a round of golf. I went out as a single, so I didn't know the people I was playing with. After leaving a putt well short, I said, "well that was rather pusillanimous of me." Getting a blank look from my co-players, I explained "it's the opposite of insouciant."That didn't seem to help much.
-
pusillanimous ... insouciant
in contrast to persiflage, I actually had to look those to two up!