Re: [lmi] Shared-library "attributes"

[Evgeniy Tarassov]

> Evgeniy--I'd like to port the change you made yesterday in
> 'wx_new.hpp', or something like it, to both our main trunks.
> Is it possible to make it more similar to 'so_attributes.hpp'?

Yes, sorry for not comparing wx_new.hpp to so_attributes.hpp. If i
understand it correctly the same define should be used for both
so_attributes.hpp and wx_new.hpp, right? (LMI_USE_SO_ATTRIBUTES)

> However, does autoconf simply not support elf "visibility" or
> msw "dll[ex|im]port" attributes? For 'wx_new.hpp', this code:

The main problem with autotools is that even if at the configuration
time we figure out what is the type of library to be build, the
libtool could change it and make a library static instead of shared.
It prefers building static in case if any of the dependent libraries
are build staticly. So if for some reason the static version of
libxml++ library is installed, then libtool will simply ignore our
options (--enable-shared --disable-static), spit a warning and it will
build a static version of lmi library. An example of the warning:

*** Warning: linker path does not have real file for library
-lboost_filesystem-mgw.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libboost_filesystem-mgw and none of the candidates passed a
file format test
*** using a file magic. Last file checked:
/usr/local/lib/libboost_filesystem-mgw.lib
*** The inter-library dependencies that have been dropped here will be
*** automatically added whenever a program is linked with this library
*** or is declared to -dlopen it.

*** Since this library must not contain undefined symbols,
*** because either the platform does not support them or
*** it was explicitly requested with -no-undefined,
*** libtool will only create a static version of it.

Libtool does define a -DBUILD_DLL symbol when it builds a shared
version of a library, but it does not define any other symbol when it
builds the code that uses the library weither it is static or shared
version of library.

So if you could accpet postponing the real problem and just modifing
wx_new.hpp, that would be great. As you have said before the patch
below will make both files look similar. I will ask Vadim's advice
about how to make it work properly with autotools (without using
auto-import feature) as soon as he is back.

Index: wx_new.hpp
===================================================================
RCS file: /sources/lmi/lmi/wx_new.hpp,v
retrieving revision 1.5.2.1
diff -u -r1.5.2.1 wx_new.hpp
--- wx_new.hpp  15 Oct 2006 23:31:20 -0000      1.5.2.1
+++ wx_new.hpp  16 Oct 2006 19:47:44 -0000
@@ -28,8 +28,8 @@

#include <cstddef> // std::size_t

-#if defined LMI_MSW
-#   if !defined HAVE_CONFIG_H // not using autoconf.
+#if defined LMI_USE_SO_ATTRIBUTES
+#   if defined LMI_MSW
#       if defined LMI_WX_NEW_BUILD_SO
#           define LMI_WX_NEW_SO __declspec(dllexport)
#       elif defined LMI_WX_NEW_USE_SO
@@ -37,12 +37,12 @@
#       else  // !defined LMI_WX_NEW_BUILD_SO && !defined LMI_WX_NEW_USE_SO
#           error Either LMI_WX_NEW_BUILD_SO or LMI_WX_NEW_USE_SO
must be defined.
#       endif // !defined LMI_WX_NEW_BUILD_SO && !defined LMI_WX_NEW_USE_SO
-#   else // using autoconf. use auto import feature on windows
+#   else // !defined LMI_MSW
#       define LMI_WX_NEW_SO
-#   endif // !defined HAVE_CONFIG_H
-#else // !defined LMI_MSW
+#   endif // defined LMI_MSW
+#else  // !defined LMI_USE_SO_ATTRIBUTES
#   define LMI_WX_NEW_SO
-#endif // defined LMI_MSW
+#endif // !defined LMI_USE_SO_ATTRIBUTES

/// When wx is used as an msw dll, memory is allocated and freed
/// across dll boundaries, and that causes mpatrol to emit spurious