Re: [lmi] Mystic fix for so-attributes linker error

[Vadim Zeitlin]

On Sun, 5 Apr 2020 00:10:58 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2017-03-08 04:25, Greg Chicares wrote:
GC> > [Vadim--The mysticity is my only problem; maybe you can explain it?]
GC> [...errors (worked around for now) with shared-object attributes...]
GC> > /opt/lmi/src/lmi[0]$make $coefficiency all build_type=so_test 
USE_SO_ATTRIBUTES=1
GC> 
GC> This led to
GC>   https://github.com/vadz/lmi/pull/56
GC> which I believe should not be applied.

 I think it might still need to be applied in a modified form, i.e. with
LMI_SO replaced with LMI_SOMETHING_ELSE_SO, so I don't close it for now.

GC> To explain why requires summarizing the mailing-list thread, as
GC> follows.
GC> 
GC>   https://lists.nongnu.org/archive/html/lmi/2017-03/msg00045.html
GC> 
GC> That's the beginning of the thread, to which this is a reply.
GC> 
GC>   https://lists.nongnu.org/archive/html/lmi/2017-03/msg00055.html
GC> 
GC> | MinGW auto-import heuristics don't seem to work well when explicit DLL
GC> | import declarations are also used and so it's unwise to rely on
GC> | auto-importing in "so_test" build where LMI_SO has a non-empty expansion.
GC> 
GC> Agreed; see below.
GC> 
GC>   https://lists.nongnu.org/archive/html/lmi/2017-03/msg00060.html
GC> 
GC> [Argues that the PR weakens encapsulation of facilities that have
GC> deliberately been sequestered in a shared library.]
GC> 
GC>   https://lists.nongnu.org/archive/html/lmi/2017-03/msg00061.html

 Thanks for the summary, this was very useful as I indeed forgot everything
about this discussion (including the fact of having it, which is really
worrisome as I don't even have a mention of any of the tasks discussed back
then in my TODO).

GC> [...can't use MinGW-w64's libstdc++ with '-Wl,--disable-auto-import'...]
GC> |  After some more tests, I realized that we could use -static-libstdc++ gcc
GC> | option to avoid this problem.
GC> 
GC> Then 'wx_test' doesn't link, but I believe that's because it shouldn't,
GC> because...
GC> 
GC> |  In fact, it's really not clear to me how can a single LMI_SO work with
GC> | more than one DLL. I believe we really need per-DLL macros, i.e. add
GC> | LMI_SKELETON_SO governed by LMI_SKELETON_{BUILD,USE}_SO, just as the
GC> | existing LMI_SO value is determined by LMI_{BUILD,USE}_SO.
GC> 
GC> Exactly. We already have these:
GC> 
GC>                       lmi_wx_new_so_attributes := -DLMI_WX_NEW_USE_SO
GC> wx_new$(SHREXT)     : lmi_wx_new_so_attributes := -DLMI_WX_NEW_BUILD_SO
GC> 
GC> and need a similar set for "SKELETON" as you describe. We just didn't
GC> think to add them when we refactored 'skeleton' into its own shared
GC> library, as part of the changes needed to add 'wx_test'; someday, we
GC> should do that.

 Do you think this day is relatively close? I.e. should I do this in the
near future, after finishing the pending task?

GC> |  But I also thought of something else: we could also change the default
GC> | visibility to hidden for the Unix builds. This should expose all the
GC> | problems due to missing/wrong LMI_SO usage too because ELF linker doesn't
GC> | do (nor even could do) any auto-linking neither.
GC> 
GC> Yes, someday we should do that, too.

 And would this day come before or after the one above it?

GC> | Why don't we use USE_SO_ATTRIBUTES=1 (and, ideally, --disable-auto-import)
GC> | by default?
GC> 
GC> I'm not sure what the historical reasons were, or whether they're
GC> still relevant. In any event, it would be interesting to compare
GC> build and run times with and without these options--maybe they'd
GC> turn out to have worthwhile advantages.

 OK, so should we/I perhaps start by doing this?

 Of course, comparing the build speed is going to be a bit difficult when
one of them doesn't build wx_test and the other one does, but I could just
temporarily skip building it in the default build too.

GC> After reviewing that discussion, I felt confident that commit 655648d765,
GC> just pushed, would be at least one step in the right direction.

 It probably is, but I wonder if we really want to use static libstdc++ or
if we could somehow still link with the dynamic library. I tried to find
the bug mentioned in the mailing list message linked from the commit
message for that commit in the hope that it might at least mention some
workaround, but couldn't. Would you already have a link to it by chance or
should I keep looking?

 More generally, it's not totally clear what is the plan here, i.e. what,
if anything, should be done. My guess would be that we should start by
measuring the performance (both build time and run-time or just the
former?) of both build variants, but I'm not really sure about it, so I'd
appreciate a confirmation.

 Thanks in advance,
VZ

pgpGtemnUYxCY.pgp
Description: PGP signature