Menu
▾
▴
1 Attachments
#138 update windows/cygwin build to use the cross-compiler
cygwin/gcc has dropped support for the "-mno-cygwin" gcc flag for creating native windows binaries, so we have to make some changes to the windows build process to use the new cygwin cross-compiler.
./configure --build=i686-pc-cygwin --host=i686-w64-mingw32
Related
From the comment it's not clear to me what the problem is
with shipping zlib1.dll as separate file. Requiring that it's
located in the same directory as the exe seems like a reasonable
default to me.
If static linking is really required on Windows now,
STATIC_LINKING should probably get a WIN32_ prefix.
I'm not sure we need all these "compiler warning if winsock2.h
is included after windows.h" comments (or the one previously
added in w32log.c,v 1.50).
The change to cgisimple.c seems to be required to unbreak the
build after w32log.c,v 1.50 and thus should probably be committed
separately.
On 7/26/16, Fabian Keil fabiankeil@users.sf.net wrote:
Mainly it's personal preference - I don't like bundling .dlls with an
executable.
it's just one more thing that can go wrong
The last one I don't know how to do an automatic work-around. If you
use the 64 bit windows cross-compiler you have to copy the 64 bit
library DLLs instead of the 32 bit library DLLs & winsetup/GNUmakefile
has everything hard-coded.
Ideally it'd be a configure option, like './configure
--static-linking' or somesuch, but that can be a later enhancement. I
don't know if anyone else wants to do static linking, but it seems
nicer to make it a general option instead of windows specific.
I can get rid of them. They're there just so the next person that
looks at the code knows that I had no idea why the include was
necessary other than getting rid of a compiler warning.
sigh removing the include of cygwin.h was a mistake that'll break
the build on cygwin 1.5 / gcc v3 -mno-cygwin -- want me to put it
back?
Thanks for the fast review!
Lee
Related
Patches:
#138"Lee" ler762@users.sf.net wrote:
Okay.
Static linking should already be supported by adding -static
to the LDFLAGS.
After thinking about it some more, that would probably be more
appropriate in this case as well and could be done automatically
in configure.in when building for Windows.
If that's not an option, the "-static" could be added to W32_LIB
where it's clear that it does not affect other platforms.
It's semantically wrong, but as W32_LIB already contains other
linker flags it could be argued that it doesn't matter.
Please do.
Please do, at least for the upcoming stable release which shouldn't
support less platforms than the beta.
If dropping support for cygwin is desirable, we could announce it in
the 3.0.26 release note and do it after the release.
Fabian
On 7/27/16, Fabian Keil fabiankeil@users.sf.net wrote:
That works, but is ugly - winsetup/GNUmakefile would look like
cd $(SOURCE) && export LDFLAGS="-static"; ./configure
--host=i686-w64-mingw32 --enable-mingw32 ...etc
I still like the idea having it as a configure option. Setting
LDFLAGS before calling configure seems like something you do if you
don't control the source code.
OK
We're not dropping support for cygwin; switching to the new cygwin
cross-compiler just means that we're dropping support for using the
no-longer-supported version of cygwin to build privoxy on windows.
Maybe I should have said "break the build >>system<< on cygwin..."?
The windows build section of the privoxy developer manual points to
the cygwin time machine to get the no-longer-supported cygwin version
1.5 (which will also get you the no-longer-supported gcc version 3
which was the last version of gcc that had the -mno-cygwin option)
The shiny new cygwin cross-compiler build changes gets us back to
using currently supported software for building privoxy on windows.
But if we're staying with the 'odd release #s=beta, even release
s=stable' then yes - we should get a 3.0.26 release out before
updating the windows/cygwin build to use the new cross-compiler.
Lee
Related
Patches:
#138"Lee" ler762@users.sf.net wrote:
I'd prefer this as well.
Great.
Fabian
On 8/2/16, Fabian Keil fabiankeil@users.sf.net wrote:
Prefer "this" as in add another configure option --enable-static-linking ?
Which, for me, ends up being
./configure --host=i686-w64-mingw32 --enable-mingw32 --enable-static-linking \
--disable-pthread --disable-dynamic-pcre --enable-zlib \
--with-docbook=yes
$ diff -U 5 /source/privoxy-3.0.26-unreleased/current/configure.in configure.in
--- /source/privoxy-3.0.26-unreleased/current/configure.in
+++ configure.in
@@ -407,10 +407,14 @@
Required by some systems to support
files larger then 2GB.],
[if test $enableval = yes; then
CFLAGS="$CFLAGS -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES
-D_LARGEFILE_SOURCE=1"
fi])
+AC_ARG_ENABLE(static-linking,
+[ --enable-static-linking Use static linking instead of
dynamic linking (ie. LDFLAGS=-static)],
+[ if test $enableval = yes; then LDFLAGS="$LDFLAGS -static"; fi ])
+
dnl Save old CFLAGS so we can restore them later, then add SPECIAL_CFLAGS
old_CFLAGS_nospecial=$CFLAGS
CFLAGS="$CFLAGS $SPECIAL_CFLAGS"
# Hack to force AutoConf to use the CFLAGS we just set
./configure --help
<.. snip ..>
Optional Features:
--disable-option-checking ignore unrecognized --enable/--with options
--disable-FEATURE do not include FEATURE (same as --enable-FEATURE=no)
--enable-FEATURE[=ARG] include FEATURE [ARG=yes]
--enable-mingw32 Use mingw32 for a Windows GUI
--enable-large-file-support Define _LARGE_FILES and friends.
Required by some systems to support
files larger then 2GB.
--enable-static-linking Use static linking instead of
dynamic linking (ie. LDFLAGS=-static)
--disable-pthread Don't use POSIX threads (pthreads)
thoughts?
Lee
"Lee" ler762@users.sf.net wrote:
Yes.
Looks good to me.
Fabian
2nd pass
see winsetup/GNUmakefile
for a windows build, the call to configure is now
cd $(SOURCE) && ./configure --host=i686-w64-mingw32 --enable-mingw32 --disable-pthread --disable-dynamic-pcre --enable-zlib --enable-static-linking
Looks good to me.
Fabian
It's been fixed for a while; I just forgot to close it