[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Testing build with native MinGW 4.9.1

From: Greg Chicares
Subject: Re: [lmi] Testing build with native MinGW 4.9.1
Date: Fri, 29 Jan 2016 00:53:39 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.3.0

On 2016-01-20 21:16, Vadim Zeitlin wrote:
>  The only still remaining question is why did I need to apply the patch to
> ensure that the alert functions are linked in with the Debian
> cross-compiler but not the native compiler. I'm not sure if it's worth
> debugging this further, however, as it's clearly an
> implementation-dependent optimization anyhow. It would be better to just
> apply the patch to make sure the problem can never arise rather than
> hoping that it doesn't.

Unfortunately, I extended your patch to 'mc_enum_types_aux.cpp' in the
hope of averting future problems, and my extension fails in this case
(where your original patch works):

  $make --jobs=6 all build_type=so_test USE_SO_ATTRIBUTES=1
  /MinGW_/bin/g++  -o lmi_wx_shared.exe \
    main_wx.o lmi_msw_res.o skeleton.dll liblmi.dll \
    -L . -L /opt/lmi/local/lib -L /opt/lmi/local/bin  -L /opt/lmi/local/lib \
    -lwx_mswu-3.1-i686-w64-mingw32 -mwindows    -lexslt -lxslt -lxml2 \
  main_wx.o: In function `lmi_force_linkmc_enum_types_aux':
  /lmi/src/lmi/main_wx.cpp:55: undefined reference to 

so I'll have to revert my extension. Evidently the problem is that I
was trying to force linking through a DLL barrier: the linker command
links a single C++ object to a couple of DLLs, one of which contains
the function whose linkage I was trying to force, but that function
is invisible by design.

I tried twiddling 'force_linking.hpp' by adding LMI_SO to various
combinations of the three declarations of
but that only introduced more diagnostics. And AFAIK there is no
standard grammar for "declspec" that works for every compiler, so this
is deep magic and the less voodoo we use the better.

I heard some exciting talk about ELF visibility attributes many years
ago, and even attempted to provide for that in 'so_attributes.hpp':

#   if defined LMI_MSW
#   elif defined __GNUC__ && 30400 <= LMI_GCC_VERSION
#       if defined LMI_BUILD_SO
#           define LMI_SO __attribute__((visibility("default")))
#       else  // !defined LMI_BUILD_SO
#           define LMI_SO
#       endif // !defined LMI_BUILD_SO
#   else  // !defined LMI_MSW and no ELF visibility support

Did that feature live up to the hopes expressed at its introduction,
so that it will be useful when building lmi on an ELF platform? and
have I even implemented visibility correctly above?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]