[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lmi-commits]  Do build DLLs, not static libraries, when cross-com
[lmi-commits]  Do build DLLs, not static libraries, when cross-compiling
Sat, 27 Feb 2016 20:56:56 +0000
Date: 2016-02-27 20:55:27 +0000 (Sat, 27 Feb 2016)
Do build DLLs, not static libraries, when cross-compiling
- Adding missing "-no-undefined" to LDFLAGS as DLLs won't be created by
libtool without this option in any case.
- Adding win32-dll to LT_INIT() options as DLLs are not created by libtool
by default (!).
- Adding a hack to disable libtool smart algorithm for determining whether the
library dependencies can be linked into a DLL because it seems completely
useless as any library can be linked into a DLL under MSW and it just
prevented any DLLs from being created because of their static Boost and
xmlwrapp libraries dependencies.
--- lmi/trunk/Makefile.am 2016-02-12 22:23:24 UTC (rev 6508)
+++ lmi/trunk/Makefile.am 2016-02-27 20:55:27 UTC (rev 6509)
@@ -207,7 +207,7 @@
libskeleton_la_CXXFLAGS = \
$(AM_CXXFLAGS) $(WX_CXXFLAGS) $(XMLWRAPP_CFLAGS) $(GTK_CFLAGS)
+libskeleton_la_LDFLAGS = -no-undefined $(AM_LDFLAGS)
libskeleton_la_LIBADD = \
--- lmi/trunk/configure.ac 2016-02-12 22:23:24 UTC (rev 6508)
+++ lmi/trunk/configure.ac 2016-02-27 20:55:27 UTC (rev 6509)
@@ -246,14 +246,23 @@
dnl === Configure libtool ===
+dnl Hack: ensure that libtool doesn't do anything "smart" to determine whether
+dnl it can link MSW DLLs with their dependencies because this is never a
+dnl problem for this platform.
+dnl This obviously relies on the details of libtool implementation and can
+dnl break with the future libtool versions (last version tested is 2.4.2).
+if test "$USE_WINDOWS" = "1"; then
dnl We can't do this at the end because we need the correct values
dnl for enable_shared/static variables which appears to be defined
dnl by AC_PROG_LIBTOOL (for ex. with --disable-shared you get only
dnl enable_shared=no before this point and enable_static=yes only after)
dnl Wx configuration part needs exactly that feature to understand
dnl what library type build we're using.
-AC_DISABLE_STATIC dnl don't waste time on static build by default
dnl use C++ compiler as we're checking for C++ libraries/headers from now on
dnl (we couldn't do it before as libtool tests must be done with C compiler)
|[Prev in Thread]
||[Next in Thread]|
- [lmi-commits]  Do build DLLs, not static libraries, when cross-compiling,
Vadim Zeitlin <=