PDA

View Full Version : Compiling static for Windows with OpenSSL



manekineko
25th February 2010, 07:31
I'm trying to build an app for Windows that's statically linked and is OpenSSL enabled.

I installed OpenSSL from here (and other posts around the Internet seem to suggest this is the best one to use for this rather than self-compiling):
http://www.slproweb.com/products/Win32OpenSSL.html

I compile QT I'm using this command (with more irrelevant flags omitted):
configure -static -release -openssl-linked -I /c/OpenSSL/include -L /c/OpenSSL/lib/MinGW -platform win32-g++

When I don't make the paths to the libraries correct, the compile of QT dies with an error that it couldn't find them. However, with that command, the compile appears to be completing successfully.

However, when I build the official QT HTTP example app, it dies with:
ld.exe: cannot find -lssleay32

I fixed this issue by copying libeay32.lib and ssleay32.lib into my qt/lib directory. The compile of the HTTP example application then finishes, but attempting to launch the application fails with the message:
The program can't start because LIBEAY32.dll is missing from your computer.

So even though the QT compile finished, it had actually silently failed to execute the -openssl-linked command. Can anyone help me with this? I've tried all sorts of things I've found from around the Internet, from moving around the .lib and .a files to renaming them to modifying the make files, but none of them have worked, and each time I try something it's taking almost an hour to recompile QT.

manekineko
25th February 2010, 17:04
Okay, even if no one is able to help with this, can anyone comment on whether they have ever seen this actually working? The silent fail of -openssl-linked is really troubling to me.

Lesiok
25th February 2010, 17:55
Standard OpenSSL is builded as DLL's. So to start Yours exe You must to have libeay32.dll and libssl32.dll in PATH or in directory with Yours exe.
This is normal behaviour with every DLL using by program. If You want to have only one exe file You must recompile all libraries as static not DLL.
Now You have only Qt compiled as static.

manekineko
25th February 2010, 19:39
Standard OpenSSL is builded as DLL's. So to start Yours exe You must to have libeay32.dll and libssl32.dll in PATH or in directory with Yours exe.
This is normal behaviour with every DLL using by program. If You want to have only one exe file You must recompile all libraries as static not DLL.
Now You have only Qt compiled as static.

I have to admit, I'm pretty inexperienced with this whole process, but how do I tell whether my openssl libraries are static? The ones I'm using do end in .lib and not .dll. I've downloaded the openssl source and I'm looking at the process of building, but apparently in order to get static, I don't have to do anything at all? Just configure and make?

olidem
25th February 2010, 21:00
hav you looked into the difference between "-openssl-linked" and "-openssl" ?

manekineko
25th February 2010, 21:18
hav you looked into the difference between "-openssl-linked" and "-openssl" ?

Are you referring to anything in particular? I'm using openssl-linked, which indicates that I wish to "Enabled linked OpenSSL support." On the other other hand, openssl indicates that I wish to "Enable run-time OpenSSL support."

I'm using openssl-linked, which is what I want for a static compile, but it's failing silently and requiring the dll's anyway.

I've been trying fruitlessl to compile something that works with this process, I've spent over 24 hours of lost development time on this now by my count. It's really mind-blowing how staggering it is to enable a basic feature of the framework, and how undocumented this is on Nokia's part.

When compiling OpenSSL on my own now using Cygwin, everything appears to compile correctly, but it's dying on QT compile with tons of errors that look like this in the openssl include headers:
c:/openssl/include/openssl/asn1.h:1: error: expected unqualified-id before '!' token
c:/openssl/include/openssl/asn1.h:1: error: stray '\255' in program

manekineko
26th February 2010, 00:06
When compiling OpenSSL on my own now using Cygwin, everything appears to compile correctly, but it's dying on QT compile with tons of errors that look like this in the openssl include headers:
c:/openssl/include/openssl/asn1.h:1: error: expected unqualified-id before '!' token
c:/openssl/include/openssl/asn1.h:1: error: stray '\255' in program

FYI, for anyone this might help, this problem is caused by make not knowing how to read symlinks on a Windows system. Each file that is in the include/openssl directory is actually a symblink and does not work and must be replaced with its actual version.

After that, OpenSSL successfully compiles. However, attempts to compile QT with it fail still, now with an error:
undefined reference _imp____ctype_ptr__

This appears to be some type of a platform incompatibility error. I wonder if it's cause by my compiling OpenSSL under cygwin and using under mingw, but when compiling OpenSSL, I passed config the mingw parameter, so it should work on mingw, so I have no idea what's causing this.

I'm now trying again with the pre-compiled openssl distributed by slproweb that I linked in my first post. I just cannot understand why openssl-linked is failing, as I have stripped the openssl directory down to the .h include files, and the .a static libraries, but somehow when I actually run the HTTP example app, it still requires an external dependency of the libeay32.dll.

I'm to the point where I'm actually considering reformatting my development system so I can follow the steps that other people tried exactly without worrying about something being misconfigured. I would do it in a heartbeat if I was sure it would work, the only thing holding me back it the thought of reformatting and reinstalling everything only to have it not work still.

olidem
26th February 2010, 09:00
Hi,
I am sorry, but I do not see the problems you are reporting.

Just 2 days ago, I also had to recompile my Qt installation to get OpenSSL support. It worked fine.

I did the following: First I downloaded a binary version of OpenSSL for Windows, you can download the installer (!) from here (http://www.slproweb.com/download/Win32OpenSSL-0_9_8l.exe). When visiting the website, make sure to not download the light version !!!

Ok, After installing this e.g. to C:\OpenSSL, I first cleaned the Qt dir mingw32-make confclean,
then I configured like

configure -openssl -I C:\OpenSSL\include -L c:\OpenSSL\lib\MinGW

Concerning the difference between -openssl and -openssl-linked, for me I would guess that -openss-linked will just *link* against the openssl-dlls, i.e. you would have to distribute them with your app, and
"-openssl" means to include the openssl-code into your executable.

I also tried to compile openssl myself some months ago (I needed it for the QCA stuff and QtCrypto). AFAIR I also did not manage to compile openssl, because of several other libs that are needed.

But the binary distribution I posted here definitely works!

Cheers

manekineko
26th February 2010, 15:14
Concerning the difference between -openssl and -openssl-linked, for me I would guess that -openss-linked will just *link* against the openssl-dlls, i.e. you would have to distribute them with your app, and
"-openssl" means to include the openssl-code into your executable.


Is your setup working for static compiles without any external dependencies? The documentation implies the exact opposite, that openssl-linked is for "Enabled linked OpenSSL support." and openssl is for "Enable run-time OpenSSL support."

olidem
26th February 2010, 15:16
Do you want to link, or do you want to have no dependencies?

manekineko
26th February 2010, 15:21
Do you want to link, or do you want to have no dependencies?

I'm trying to be statically-linked, with no external dll dependencies at runtime.

olidem
26th February 2010, 15:22
then you need "openssl" and NOT "openssl-linked"

wysota
26th February 2010, 15:23
openssl-linked means OpenSSL libraries are linked to QtNetwork library meaning that each application using QtNetwork needs OpenSSL regardless whether it is actually using it or not. Without openssl-linked openssl dependency is resolved at runtime when SSL functionality is required. This has nothing to do with having OpenSSL linked statically or not - in both cases a dynamic OpenSSL library is used. If you want everything in one binary, you need to have all your application's dependencies (like Qt) and all those dependencies dependencies (like OpenSSL) and their depenencies built statically. Only then you will get "one huge binary to rule them" ;)

olidem
26th February 2010, 15:32
Hmmm,
but isn't it the case that if you choose "-openssl", then the openssl-code is bulit-in the QtNetwork4.dll and one does not have to deploy the ssl-dlls?

manekineko
26th February 2010, 15:33
openssl-linked means OpenSSL libraries are linked to QtNetwork library meaning that each application using QtNetwork needs OpenSSL regardless whether it is actually using it or not. Without openssl-linked openssl dependency is resolved at runtime when SSL functionality is required. This has nothing to do with having OpenSSL linked statically or not - in both cases a dynamic OpenSSL library is used. If you want everything in one binary, you need to have all your application's dependencies (like Qt) and all those dependencies dependencies (like OpenSSL) and their depenencies built statically. Only then you will get "one huge binary to rule them" ;)

Interesting, so under what circumstances would openssl-linked be advantageous?

I'm really confused now. My copy of OpenSSL seems like it must be compiled statically, because I've wiped out everything in the OpenSSL directory except for the .a static libraries, and the /include/.h header include files. Nevertheless, when my application compiles, it's still demanding the OpenSSL dlls (and no other DLLs, as everything else from QT to other 3rd party libraries has been compiled in statically).

wysota
26th February 2010, 18:41
but isn't it the case that if you choose "-openssl", then the openssl-code is bulit-in the QtNetwork4.dll and one does not have to deploy the ssl-dlls?
No. It means that if the target system has OpenSSL installed, Qt will pick it up during runtime and use it if needed. If OpenSSL is unavailable, Qt will continue without SSL support.


Interesting, so under what circumstances would openssl-linked be advantageous?
I can think of two cases. First is that the application works a bit faster because Qt doesn't have to resolve the SSL symbols during runtime. The other is that you make sure your application won't even start if SSL is unavailable (so it's harder to forget to deploy OpenSSL libraries).


My copy of OpenSSL seems like it must be compiled statically
Did you compile it statically or do you assume it is compiled statically because of existance of the .a files?


because I've wiped out everything in the OpenSSL directory except for the .a static libraries
These are probably not the static libraries but stubs Windows compilers need for linking DLLs (so called import libraries). Check their size - if they are smaller than the DLL files then they are import libraries.

manekineko
27th February 2010, 19:19
I can think of two cases. First is that the application works a bit faster because Qt doesn't have to resolve the SSL symbols during runtime. The other is that you make sure your application won't even start if SSL is unavailable (so it's harder to forget to deploy OpenSSL libraries).

But the ssl-linked command is passed in when compiling QT, which means it would apply to all QT applications being built on that system. Your points make sense, but they seem to be really obscure use cases where you want to alter your entire framework build just for the one application.



Did you compile it statically or do you assume it is compiled statically because of existance of the .a files?


These are probably not the static libraries but stubs Windows compilers need for linking DLLs (so called import libraries). Check their size - if they are smaller than the DLL files then they are import libraries.

The sizes on the .a files looked good. 2246 KB for libeay32.a and 168 KB for lssleay32.a. However, you must be right, since I couldn't get anywhere with these, but then tried a different build of OpenSSL, and everything immediately worked in terms of static compiling.

Thanks a lot for the help everybody!

wysota
28th February 2010, 13:37
But the ssl-linked command is passed in when compiling QT, which means it would apply to all QT applications being built on that system.
Yes, that's correct, that's why it's not used by default.


Your points make sense, but they seem to be really obscure use cases where you want to alter your entire framework build just for the one application.
In my opinion building Qt statically only makes sense for one or two applications in the first place. Unless of course you like wasting disk space and RAM.


The sizes on the .a files looked good. 2246 KB for libeay32.a and 168 KB for lssleay32.a.
And the DLLs for them?

wagseye
24th February 2012, 20:01
I had this same problem, and since there wasn't a clear solution in the thread here's some additional information:

1. Use the -openssl-linked flag
2. Pass the includes folder to the configure script using '-I c:\path\to\includes'
3. Pass the lib folder using '-L c:\path\to\lib'
4. You need to link against some of the Windows libraries as well. To get it to build successfully I had to include these flags: '-l ws2_32 -l advapi32 -l gdi32 -l user32 -l crypt32'

So overall the openssl portion of the configure command looked like this:
'-openssl-linked -I c:\path\to\includes -L c:\path\to\lib -l ws2_32 -l advapi32 -l gdi32 -l user32 -l crypt32'

After building with these parameters I was able to get a WebKit WebView to connect to a server over https without having copies of libeay32.dll or ssleay32.dll installed.

rbeede
23rd March 2012, 22:13
I had this same problem, and since there wasn't a clear solution in the thread here's some additional information:
After building with these parameters I was able to get a WebKit WebView to connect to a server over https without having copies of libeay32.dll or ssleay32.dll installed.



Are you sure you didn't install libeay32.dll into your C:\Windows\System32 directory on your own machine? I tried this with the OpenSSL install from http://www.slproweb.com/download/Win32OpenSSL-1_0_1.exe and it didn't work.

A quick check is to take your "static" executable and launch it using a cmd prompt where you've SET PATH= (to clear out the path which removes libeay32.dll from anywhere but the current directory).

Anyone have another source for OpenSSL for Win32 that has true static libraries?