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

[Greg Chicares]

On 2017-03-08 04:25, Greg Chicares wrote:
> [Vadim--The mysticity is my only problem; maybe you can explain it?]
[...errors (worked around for now) with shared-object attributes...]
> /opt/lmi/src/lmi[0]$make $coefficiency all build_type=so_test 
> USE_SO_ATTRIBUTES=1

This led to
  https://github.com/vadz/lmi/pull/56
which I believe should not be applied. To explain why requires
summarizing the mailing-list thread, as follows.

  https://lists.nongnu.org/archive/html/lmi/2017-03/msg00045.html

That's the beginning of the thread, to which this is a reply.

  https://lists.nongnu.org/archive/html/lmi/2017-03/msg00055.html

| MinGW auto-import heuristics don't seem to work well when explicit DLL
| import declarations are also used and so it's unwise to rely on
| auto-importing in "so_test" build where LMI_SO has a non-empty expansion.

Agreed; see below.

  https://lists.nongnu.org/archive/html/lmi/2017-03/msg00060.html

[Argues that the PR weakens encapsulation of facilities that have
deliberately been sequestered in a shared library.]

  https://lists.nongnu.org/archive/html/lmi/2017-03/msg00061.html

[...can't use MinGW-w64's libstdc++ with '-Wl,--disable-auto-import'...]
|  After some more tests, I realized that we could use -static-libstdc++ gcc
| option to avoid this problem.

Then 'wx_test' doesn't link, but I believe that's because it shouldn't,
because...

|  In fact, it's really not clear to me how can a single LMI_SO work with
| more than one DLL. I believe we really need per-DLL macros, i.e. add
| LMI_SKELETON_SO governed by LMI_SKELETON_{BUILD,USE}_SO, just as the
| existing LMI_SO value is determined by LMI_{BUILD,USE}_SO.

Exactly. We already have these:

                      lmi_wx_new_so_attributes := -DLMI_WX_NEW_USE_SO
wx_new$(SHREXT)     : lmi_wx_new_so_attributes := -DLMI_WX_NEW_BUILD_SO

and need a similar set for "SKELETON" as you describe. We just didn't
think to add them when we refactored 'skeleton' into its own shared
library, as part of the changes needed to add 'wx_test'; someday, we
should do that.

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

Yes, someday we should do that, too.

| Why don't we use USE_SO_ATTRIBUTES=1 (and, ideally, --disable-auto-import)
| by default?

I'm not sure what the historical reasons were, or whether they're
still relevant. In any event, it would be interesting to compare
build and run times with and without these options--maybe they'd
turn out to have worthwhile advantages.

  https://lists.nongnu.org/archive/html/lmi/2017-03/msg00062.html

[...this gives the reasoning for some 'mc_enum' design decisions, and
suggests that the "historical reasons" in the preceding paragraph had
to do with "direct" linking of an msw DLL (with no import library)...]

  https://lists.nongnu.org/archive/html/lmi/2017-03/msg00063.html

[...suggests that msw "direct" linking may no longer be as important...]

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