[Issues] [mod_gnutls 0000099]: mod_gnutls build fails to produce shared library under CygWin

Mantis Bug Tracker issues at outoforder.cc
Mon Sep 26 00:26:09 EDT 2011

The following issue requires your FEEDBACK. 
Reported By:                TimeHorse
Assigned To:                dashula
Project:                    mod_gnutls
Issue ID:                   99
Category:                   Compile or Build
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     feedback
Target Version:             0.6
Apache Version:             Apache 2.2.6 CYGWIN 
Date Submitted:             2009-05-31 21:15 EEST
Last Modified:              2011-09-26 06:26 EET
Summary:                    mod_gnutls build fails to produce shared library
under CygWin
When trying to build mod_gnutls for the current release of CYGWIN, the build
produces the static libraries but fails to produce the required shared library
(*.so).  I have back-verified this fails also in version 0.2.0 and 0.4.3 of the
mod_gnutls software.

The system I am using has the following versions:
Apache 2.2.6
GnuTLS 2.4.1
CygWin DLL 1.2.25-15
APR 1.3.3-3
APR-Utils 1.3.4-1
ap_memcache 0.7.0

Additional Information: 
The problem stems from confusion about linking with other shared libraries,
which in the current version of CYGWIN should be possible, though quirky.  For
instance, CYGWIN uses WIN32-style library importation and exportation rules,
meaning that shared headers for a shared library requires __declspec(dllimport)
and exported symbols for a shared library should be declared with
__declspec(dllexport).  This, however, should be invisible to developers using
the gnu utilities on CygWin.  There are, however, quirks with how libraries are
laid out under CygWin, where a static library has its normal, UNIX-like
lib/libfoo.a name, but it's shared library header is lib/libfoo.dll.la and the
shared library is typically bin/cygfoo.dll.  This, again, should all be handled
by Cygwin and be invisible to the developer.  There is a quirk, though, with
some libraries, such as the earlier httpd from apache 1.x having the shared
library name of bin/libhttpd.dll rather than the appropriate bin/cyghttpd.dll
for the CygWin platform.

Given all this, I tried using a more aggressive link with the apr1 libtool and
turning on various linker options to try and force more information out of the
compiler.  This produces the results in the second attached build log:

make all LDFLAGS="-W1 -shared -avoid-version -no-undefined -R/usr/bin -L/usr/bin
-L/usr/lib -ldl -shrext=.so --enable-auto-import /usr/lib/libapr-1.la"
libdir=/usr/lib/apache2 LIBTOOL=/usr/share/apr/build-1/libtool


 (0000148) TimeHorse (reporter) - 2009-06-14 18:50
Build still does not produce .so file as of version 0.5.5.  Statically linked
files are built, but the .so file, critical for use with Apache, is silently
ignored and never generated.

Now, this make command:

make all LDFLAGS="-W1 -shared -avoid-version -no-undefined -R/usr/bin -L/usr/bin
-L/usr/lib -ldl -shrext=.so --enable-auto-import /usr/lib/libapr-1.la
/usr/lib/libhttpd2core.la" libdir=/usr/lib/apache2

Does make a seemingly valid shared library by the name cygmod_gnutls.dll with
headers in libmod_gnutls.dll.a but as you can see this is a massive make line
which forces me to link my module statically with the latest APR library and the
Apache 2 core.  This strikes me as inelegant for a module, not to mention that I
had to hardcode the path to the libtool since you were not using the libtool
appropriate for the Apache Portable Runtime, had to turn on warnings, force the
target to sharded, turn off versions for no undefined symbols to make sure the
build doesn't silently build the statically linked file and neglect the critical
shared library build, had to add /usr/bin to the run-time, shared library path,
/usr/bin and /usr/lib to the link-time library search path, add dl or the
dynamic loading library to the list of linked modules and force auto import of
modules.  You can see that I tried to force the extension of the shared library
to '.so' but this actually has no effect.  I also had to force the libdir to be
the apache library directory.

Anyway, the install just needs to copy src/.libs/cygmod_gnutls.dll to
/usr/lib/apache2/mod_gnutls.so as well as src/.libs/libmod_gnutls.dll.a to
/usr/lib/apache2/mod_gnutls.dll.a and src/.libs/libmod_gnutls.la to

Anyone who needs to compile mod_gnutls for CYGWIN can follow these complicated
build instructions to get the software compiled.  Specifically, the
counter-intuitive make command above and the three manual copy instructions as
described below:

$ ./configure --with-apxs=/usr/sbin/apxs2


$ make all LDFLAGS="-W1 -shared -avoid-version -no-undefined -R/usr/bin
-L/usr/bin -L/usr/lib -ldl -shrext=.so --enable-auto-import /usr/lib/libapr-1.la
/usr/lib/libhttpd2core.la" libdir=/usr/lib/apache2


$ cp -f src/.libs/cygmod_gnutls.dll /usr/lib/apache2/mod_gnutls.so
$ cp -f src/.libs/libmod_gnutls.dll.a /usr/lib/apache2/mod_gnutls.dll.a
$ cp -f src/.libs/libmod_gnutls.la /usr/lib/apache2/mod_gnutls.la

Good luck for those who use these instructions and if you need any further help
integrating these instructions into a common build, I'll be happy to work with
you further. 

 (0000155) nmav (manager) - 2009-06-30 21:05
The shared library is generated with libtool thus I wasn't much involved in the
generation of it. However if you know any other apache module that could make a
shared library at windows, we could check what it is doing at configure time. 

 (0000164) TimeHorse (reporter) - 2009-07-04 18:52
Well, of the various apache mods I've tried to compile, the one that went the
smoothest under CYGWIN was mod_wsgi (http://code.google.com/p/modwsgi/).  This
is also a VERY small library with one 1 source file though it does expect Python
to be installed.  It built the .so file perfectly using the apxs2 binary for the
link step.  As I suggested, it's probably best to use the libtool associated
with the APR rather than the generic system-wide libtool since the APR is meant
to be platform independent and built in this case specifically for CYGWIN. 
Since the mod_wsgi package is just the 1 source file, the compilation of it
combines build with link so it's maybe not the best answer but the apxs2 can
handle linking and understands Apache so generally it's the best way to create
modules in my experience.  Hope that helps and thanks again for looking into

Line used to build and link mod_wsgi:

$(APXS) -c $(CPPFLAGS) $(CFLAGS) mod_wsgi.c $(LDFLAGS) $(LDLIBS)

Where APXS is apxs2 

 (0000273) dashula (manager) - 2011-07-08 16:36
Will look into this as soon as I have some free time.
Will try include a fix in mod_gnutls 0.6.0 (Scheduled for Aug 2011). 

 (0000289) dashula (manager) - 2011-09-26 06:26
Can you confirm this with the latest version too?


Issue History 
Date Modified    Username       Field                    Change               
2009-05-31 21:15 TimeHorse      New Issue                                    
2009-05-31 21:15 TimeHorse      File Added: config.log                       
2009-05-31 21:15 TimeHorse      Apache Version            => Apache 2.2.6 CYGWIN
2009-05-31 21:16 TimeHorse      File Added: build.log                        
2009-05-31 21:16 TimeHorse      File Added: build2.log                       
2009-06-14 18:50 TimeHorse      Note Added: 0000148                          
2009-06-30 21:05 nmav           Note Added: 0000155                          
2009-07-04 18:52 TimeHorse      Note Added: 0000164                          
2011-07-08 16:36 dashula        Note Added: 0000273                          
2011-07-08 16:36 dashula        Assigned To               => dashula         
2011-07-08 16:36 dashula        Status                   new => acknowledged 
2011-07-22 00:12 dashula        Target Version            => 0.6             
2011-09-26 06:26 dashula        Note Added: 0000289                          
2011-09-26 06:26 dashula        Status                   acknowledged =>

More information about the Issues mailing list