Link OpenSSL statically for Win32
Windows is painful enough to deal with already, without shipping "precompiled" binaries of rtmpdump which require you to fetch OpenSSL separately. Especially given that OpenSSL breaks binary compatibility so often. Wouldn't it be much nicer to build it with -static, so that people who download the binaries can just run them? This builds a useful binary (http://david.woodhou.se/rtmpdump.exe) on Fedora 12 with the mingw32-zlib-static and mingw32-openssl-static development packages installed. Index: Makefile =================================================================== --- Makefile (revision 432) +++ Makefile (working copy) @@ -37,7 +37,7 @@ @$(MAKE) $(MAKEFLAGS) MF="$(MAKEFLAGS)" progs mingw: - @$(MAKE) CROSS_COMPILE=mingw32- LIBS="$(LIBS) -lws2_32 -lwinmm -lgdi32" THREADLIB= EXT=.exe $(MAKEFLAGS) progs + @$(MAKE) CROSS_COMPILE=mingw32- LIBS="-static $(LIBS) -lws2_32 -lwinmm -lgdi32" THREADLIB= EXT=.exe $(MAKEFLAGS) progs cygwin: @$(MAKE) XCFLAGS=-static XLDFLAGS="-static-libgcc -static" EXT=.exe $(MAKEFLAGS) progs -- dwmw2
David Woodhouse wrote:
Windows is painful enough to deal with already, without shipping "precompiled" binaries of rtmpdump which require you to fetch OpenSSL separately. Especially given that OpenSSL breaks binary compatibility so often.
Wouldn't it be much nicer to build it with -static, so that people who download the binaries can just run them?
It might be, but the OpenSSL license is incompatible with the GPL, so it would be illegal for us to distribute such a binary. What end-users build and run is their own business of course. Also, there are no official OpenSSL packages on www.mingw.org, otherwise I would have referred Windows users there already.
On Sun, 2010-04-18 at 11:44 -0700, Howard Chu wrote:
It might be, but the OpenSSL license is incompatible with the GPL, so it would be illegal for us to distribute such a binary. What end-users build and run is their own business of course.
Ah, crap. Of course. Is the GNUTLS build expected to work on Windows? I get this... [dwmw2@macbook rtmpdump]$ make CC=/usr/bin/i686-pc-mingw32-gcc mingw AR=/usr/bin/i686-pc-mingw32-ar mingw CRYPTO=GNUTLS make[1]: Entering directory `/home/dwmw2/working/rtmpdump' /usr/bin/i686-pc-mingw32-gcc -Wall -DRTMPDUMP_VERSION=\"v2.2c\" -O2 -c -o rtmpdump.o rtmpdump.c make[2]: Entering directory `/home/dwmw2/working/rtmpdump/librtmp' /usr/bin/i686-pc-mingw32-gcc -Wall -DRTMPDUMP_VERSION=\"v2.2c\" -DUSE_GNUTLS -O2 -c -o rtmp.o rtmp.c In file included from /usr/i686-pc-mingw32/sys-root/mingw/include/gcrypt.h:35, from handshake.h:27, from rtmp.c:123: /usr/i686-pc-mingw32/sys-root/mingw/include/ws2tcpip.h:16:2: error: #error "ws2tcpip.h is not compatible with winsock.h. Include winsock2.h instead." In file included from /usr/i686-pc-mingw32/sys-root/mingw/include/gcrypt.h:35, from handshake.h:27, from rtmp.c:123: /usr/i686-pc-mingw32/sys-root/mingw/include/ws2tcpip.h:124: error: redefinition of 'struct ip_mreq' /usr/i686-pc-mingw32/sys-root/mingw/include/ws2tcpip.h:272: error: two or more data types in declaration specifiers make[2]: *** [rtmp.o] Error 1 make[2]: Leaving directory `/home/dwmw2/working/rtmpdump/librtmp' -- dwmw2
On Sun, 2010-04-18 at 20:07 +0100, David Woodhouse wrote:
Is the GNUTLS build expected to work on Windows? I get this...
Seems to be fixed if I do this. Winsock2 was apparently built in to Win98 and NT4, so I suspect it's possibly OK for us to update to it now. I mostly have no clue about Windows though. I also need to link libgcrypt explicitly, which we arguably ought to do anyway. Index: librtmp/rtmp_sys.h =================================================================== --- librtmp/rtmp_sys.h (revision 432) +++ librtmp/rtmp_sys.h (working copy) @@ -22,13 +22,13 @@ */ #ifdef WIN32 -#include <winsock.h> +#include <winsock2.h> +#include <ws2tcpip.h> #define GetSockError() WSAGetLastError() #define setsockopt(a,b,c,d,e) (setsockopt)(a,b,c,(const char *)d,(int)e) #define EWOULDBLOCK WSAETIMEDOUT /* we don't use nonblocking, but we do use timeouts */ #define sleep(n) Sleep(n*1000) #define msleep(n) Sleep(n) -#define socklen_t int #define SET_RCVTIMEO(tv,s) int tv = s*1000 #else #include <sys/types.h> Index: Makefile =================================================================== --- Makefile (revision 432) +++ Makefile (working copy) @@ -5,7 +5,7 @@ CRYPTO=OPENSSL #CRYPTO=GNUTLS -LIB_GNUTLS=-lgnutls +LIB_GNUTLS=-lgnutls -lgcrypt LIB_OPENSSL=-lssl -lcrypto CRYPTO_LIB=$(LIB_$(CRYPTO)) DEF_=-DNO_CRYPTO -- dwmw2
David Woodhouse wrote:
On Sun, 2010-04-18 at 11:44 -0700, Howard Chu wrote:
It might be, but the OpenSSL license is incompatible with the GPL, so it would be illegal for us to distribute such a binary. What end-users build and run is their own business of course.
Ah, crap. Of course.
Is the GNUTLS build expected to work on Windows? I get this...
I hadn't tried it. But there's no particular reason we're using winsock.h instead of winsock2.h. Fixing that seems to clear this up.
[dwmw2@macbook rtmpdump]$ make CC=/usr/bin/i686-pc-mingw32-gcc mingw AR=/usr/bin/i686-pc-mingw32-ar mingw CRYPTO=GNUTLS make[1]: Entering directory `/home/dwmw2/working/rtmpdump' /usr/bin/i686-pc-mingw32-gcc -Wall -DRTMPDUMP_VERSION=\"v2.2c\" -O2 -c -o rtmpdump.o rtmpdump.c make[2]: Entering directory `/home/dwmw2/working/rtmpdump/librtmp' /usr/bin/i686-pc-mingw32-gcc -Wall -DRTMPDUMP_VERSION=\"v2.2c\" -DUSE_GNUTLS -O2 -c -o rtmp.o rtmp.c In file included from /usr/i686-pc-mingw32/sys-root/mingw/include/gcrypt.h:35, from handshake.h:27, from rtmp.c:123: /usr/i686-pc-mingw32/sys-root/mingw/include/ws2tcpip.h:16:2: error: #error "ws2tcpip.h is not compatible with winsock.h. Include winsock2.h instead." In file included from /usr/i686-pc-mingw32/sys-root/mingw/include/gcrypt.h:35, from handshake.h:27, from rtmp.c:123: /usr/i686-pc-mingw32/sys-root/mingw/include/ws2tcpip.h:124: error: redefinition of 'struct ip_mreq' /usr/i686-pc-mingw32/sys-root/mingw/include/ws2tcpip.h:272: error: two or more data types in declaration specifiers make[2]: *** [rtmp.o] Error 1 make[2]: Leaving directory `/home/dwmw2/working/rtmpdump/librtmp'
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
On 19/04/2010 4:14 AM, Howard Chu wrote:
It might be, but the OpenSSL license is incompatible with the GPL, so it would be illegal for us to distribute such a binary. What end-users build and run is their own business of course.
Have you read: http://www.openssl.org/support/faq.html#LEGAL2 In this case, it seems to me that the onus is on you, Howard, to give the OK? Regards, Stefan Zakarias.
Stef wrote:
On 19/04/2010 4:14 AM, Howard Chu wrote:
It might be, but the OpenSSL license is incompatible with the GPL, so it would be illegal for us to distribute such a binary. What end-users build and run is their own business of course.
Have you read:
http://www.openssl.org/support/faq.html#LEGAL2
In this case, it seems to me that the onus is on you, Howard, to give the OK?
I can't make license changes unilaterally; there are other authors involved, and it takes a bit of effort to contact them all.
On Sun, 2010-04-18 at 20:55 -0700, Howard Chu wrote:
I can't make license changes unilaterally; there are other authors involved, and it takes a bit of effort to contact them all.
Note that librtmp itself isn't a problem; that's under LGPL so it _is_ actually compatible with OpenSSL. It's only the programs which have a problematic licence. Relicensing just _those_ would be sufficient, and may be slightly easier than relicensing the whole of librtmp. But using gnutls is probably a better fix. -- dwmw2
On 19/04/2010 3:38 PM, David Woodhouse wrote:
On Sun, 2010-04-18 at 20:55 -0700, Howard Chu wrote:
I can't make license changes unilaterally; there are other authors involved, and it takes a bit of effort to contact them all.
Note that librtmp itself isn't a problem; that's under LGPL so it _is_ actually compatible with OpenSSL. It's only the programs which have a problematic licence. Relicensing just _those_ would be sufficient, and may be slightly easier than relicensing the whole of librtmp.
But using gnutls is probably a better fix.
It would be if it wasn't such a pig/drag to get it to compile in MS Visual Studio. (I have a statically-built rtmpdump.exe here and working using OpenSSL.)
On Mon, 2010-04-19 at 15:48 +0930, Stef wrote:
It would be if it wasn't such a pig/drag to get it to compile in MS Visual Studio. (I have a statically-built rtmpdump.exe here and working using OpenSSL.)
Well, if you're actually going to boot into Windows and try to do stuff there then _everything_ is going to be painful. That's what we have mingw32 for. I have a statically-built rtmpdump.exe here that I can legally distribute -- so other people can just use it without having to mess around with finding a version of OpenSSL and praying that it's binary-compatible. But I don't think anyone is suggesting that we _remove_ the OpenSSL support from librtmp. Currently you have the choice when you build it, so you can still build your OpenSSL version if you want. -- dwmw2
On 19/04/2010 4:01 PM, David Woodhouse wrote:
I have a statically-built rtmpdump.exe here that I can legally distribute -- so other people can just use it without having to mess around with finding a version of OpenSSL and praying that it's binary-compatible.
So currently I can distribute my "version" of rtmpdump.exe that is built with the statically-built OpenSSL as part of a project I'm involved in? (I currently build rtmpdump for some other people who use it for their projects (they prefer the static build too)). Regards, Stefan Zakarias.
On Mon, 2010-04-19 at 17:19 +0930, Stef wrote:
So currently I can distribute my "version" of rtmpdump.exe that is built with the statically-built OpenSSL as part of a project I'm involved in?
(I currently build rtmpdump for some other people who use it for their projects (they prefer the static build too)).
As Howard pointed out, you're not allowed to distribute it statically linked with OpenSSL. The licence on rtmpdump.c (but not the rest of librtmp) is incompatible with the OpenSSL licence. If you want to legally distribute a static binary, it needs to be the gnutls build. Like the one at http://david.woodhou.se/rtmpdump.exe -- dwmw2
On 19/04/2010 7:26 PM, David Woodhouse wrote:
On Mon, 2010-04-19 at 17:19 +0930, Stef wrote:
So currently I can distribute my "version" of rtmpdump.exe that is built with the statically-built OpenSSL as part of a project I'm involved in?
(I currently build rtmpdump for some other people who use it for their projects (they prefer the static build too)).
As Howard pointed out, you're not allowed to distribute it statically linked with OpenSSL. The licence on rtmpdump.c (but not the rest of librtmp) is incompatible with the OpenSSL licence.
If you want to legally distribute a static binary, it needs to be the gnutls build. Like the one at http://david.woodhou.se/rtmpdump.exe
Thanks David. Unfortunately, "hashswf.c" and "rtmp.c" in the "librtmp" use the OpenSSL stuff too, don't they? So that puts a damper on anything using the librtmp library as well unless it's built to use the dynamic DLL. Regards, Stefan Zakarias.
On Mon, 2010-04-19 at 20:15 +0930, Stef wrote:
Unfortunately, "hashswf.c" and "rtmp.c" in the "librtmp" use the OpenSSL stuff too, don't they? So that puts a damper on anything using the librtmp library as well unless it's built to use the dynamic DLL.
Those files are licensed under LGPL, not GPL. So there is no problem with linking to OpenSSL. But still, as I said, they can be built to use GnuTLS instead of OpenSSL. And then _even_ the GPL-licensed tools like rtmpdump can be statically linked quite happily. -- dwmw2
On 19/04/2010 8:53 PM, David Woodhouse wrote:
On Mon, 2010-04-19 at 20:15 +0930, Stef wrote:
Unfortunately, "hashswf.c" and "rtmp.c" in the "librtmp" use the OpenSSL stuff too, don't they? So that puts a damper on anything using the librtmp library as well unless it's built to use the dynamic DLL.
Those files are licensed under LGPL, not GPL. So there is no problem with linking to OpenSSL.
But still, as I said, they can be built to use GnuTLS instead of OpenSSL. And then _even_ the GPL-licensed tools like rtmpdump can be statically linked quite happily.
Agreed. Howard should put a note in the README/COPYING pointing out the issue with distributing Windows (Mac too?) versions of rtmpdump and static-built OpenSSL. E.g: It can only be re-distributed as long as the executable is built to use the OpenSSL dynamic-link-libs (personal use is fine with static-built OpenSSL) or GnuTLS (static or dynamic). Either that or drop OpenSSL entirely and just use GnuTLS exclusively. Regards, Stefan Zakarias.
On Mon, 2010-04-19 at 22:21 +0930, Stef wrote:
On 19/04/2010 8:53 PM, David Woodhouse wrote:
On Mon, 2010-04-19 at 20:15 +0930, Stef wrote:
Unfortunately, "hashswf.c" and "rtmp.c" in the "librtmp" use the OpenSSL stuff too, don't they? So that puts a damper on anything using the librtmp library as well unless it's built to use the dynamic DLL.
Those files are licensed under LGPL, not GPL. So there is no problem with linking to OpenSSL.
But still, as I said, they can be built to use GnuTLS instead of OpenSSL. And then _even_ the GPL-licensed tools like rtmpdump can be statically linked quite happily.
Agreed.
Howard should put a note in the README/COPYING pointing out the issue with distributing Windows (Mac too?) versions of rtmpdump and static-built OpenSSL. E.g: It can only be re-distributed as long as the executable is built to use the OpenSSL dynamic-link-libs (personal use is fine with static-built OpenSSL) or GnuTLS (static or dynamic).
That might be wise. Would you care to suggest that again, in 'diff -up' form? It isn't really an issue on Mac -- there's a dynamic OpenSSL library on Mac OS as part of the default install, so you can just ship rtmpdump linked against that and everybody's happy.
Either that or drop OpenSSL entirely and just use GnuTLS exclusively.
There are people who will still want to use OpenSSL for their local builds. Didn't somebody say only last night that it was easier to build OpenSSL on Windows than it is to build GnuTLS? (Although if we can ship fully-functional binaries for the majority of Windows users, perhaps that becomes less of an issue?) -- dwmw2
On 19/04/2010 10:29 PM, David Woodhouse wrote:
On Mon, 2010-04-19 at 22:21 +0930, Stef wrote:
On 19/04/2010 8:53 PM, David Woodhouse wrote:
On Mon, 2010-04-19 at 20:15 +0930, Stef wrote:
Unfortunately, "hashswf.c" and "rtmp.c" in the "librtmp" use the OpenSSL stuff too, don't they? So that puts a damper on anything using the librtmp library as well unless it's built to use the dynamic DLL.
Those files are licensed under LGPL, not GPL. So there is no problem with linking to OpenSSL.
But still, as I said, they can be built to use GnuTLS instead of OpenSSL. And then _even_ the GPL-licensed tools like rtmpdump can be statically linked quite happily.
Agreed.
Howard should put a note in the README/COPYING pointing out the issue with distributing Windows (Mac too?) versions of rtmpdump and static-built OpenSSL. E.g: It can only be re-distributed as long as the executable is built to use the OpenSSL dynamic-link-libs (personal use is fine with static-built OpenSSL) or GnuTLS (static or dynamic).
That might be wise. Would you care to suggest that again, in 'diff -up' form?
OK. I'll get to it later tomorrow (time for bed here) unless Howard wants to do it. ;)
Either that or drop OpenSSL entirely and just use GnuTLS exclusively.
There are people who will still want to use OpenSSL for their local builds. Didn't somebody say only last night that it was easier to build OpenSSL on Windows than it is to build GnuTLS?
(Although if we can ship fully-functional binaries for the majority of Windows users, perhaps that becomes less of an issue?)
Yes, it is easier to build OpenSSL on Windows than GnuTLS when using MS Visual Studio. However, I'd rather supply the fully-functional binaries too. Issues can be better dealt with when the binary is a known quantity (or quality). Regards, Stefan Zakarias.
On Sun, 2010-04-18 at 11:44 -0700, Howard Chu wrote:
It might be, but the OpenSSL license is incompatible with the GPL, so it would be illegal for us to distribute such a binary. What end-users build and run is their own business of course.
Are you going to build the 2.2d win32 binaries with static gnutls and zlib? That would be extremely useful. -- dwmw2
David Woodhouse wrote:
On Sun, 2010-04-18 at 11:44 -0700, Howard Chu wrote:
It might be, but the OpenSSL license is incompatible with the GPL, so it would be illegal for us to distribute such a binary. What end-users build and run is their own business of course.
Are you going to build the 2.2d win32 binaries with static gnutls and zlib? That would be extremely useful.
Maybe with polarssl, not gnutls. Will see.
participants (3)
-
David Woodhouse -
Howard Chu -
Stef