[gnutls-devel] Guile bindings for GnuTLS don't build as shared library on MinGW
nmav at gnutls.org
Wed Dec 10 19:29:50 CET 2014
On Wed, 2014-12-10 at 18:45 +0100, Ludovic Courtès wrote:
> > mv -f .deps/guile_gnutls_v_2_la-utils.Tpo .deps/guile_gnutls_v_2_la-utils.Plo
> > /bin/sh ../../libtool --tag=CC --mode=link gcc -Wno-strict-prototypes -I../../gl -I../../gl -Id:/usr/include/guile/2.0 -Id:/usr/include -O2 -g3 -module -g3 -o guile-gnutls-v-2.la -rpath d:/usr/lib/guile/2.0 guile_gnutls_v_2_la-core.lo guile_gnutls_v_2_la-errors.lo guile_gnutls_v_2_la-utils.lo ../../lib/libgnutls.la ../../gl/libgnu.la -Ld:/usr/lib -lguile-2.0 -lgc -lintl -lregex
> > libtool: link: warning: undefined symbols not allowed in i686-pc-mingw32 shared libraries
> > libtool: link: rm -fr .libs/guile-gnutls-v-2.a .libs/guile-gnutls-v-2.la .libs/guile-gnutls-v-2.lai
> Here it chooses to build the static library.
> The command line lacks -no-undefined compared to the other one you
> posted, which may be the explanation. Could you try:
> make clean -C guile
> make -C guile LDFLAGS=-no-undefined
> >> The ‘-module’ option is used to create “a library that can be dlopened”
> >> (info "(libtool) Link mode"), and is a prerequisite when leaving out the
> >> ‘lib’ prefix.
> > How is this “library that can be dlopened” different from a "normal"
> > shared library?
> I think some OSes view shared libraries as something different from
> dlopenable modules (early OS X had .dylib for the former and .so for the
> latter, IIRC.) There’s also the “dlpreopening” concept for OSes lacking
> dlopen–which may be irrelevant nowadays (info "(libtool) Dlpreopening").
In the main library we use -no-undefined in the link flags by default.
That allows to make a shared library in windows.
More information about the Gnutls-devel