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

[Greg Chicares]

On 2020-04-05 00:34, Vadim Zeitlin wrote:
> 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.

Okay.

> GC> [...] 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?

By "someday", I mean as soon as today if you do it, or much later if I do it.
It's worthwhile. I just don't have time to explore it all myself right now.

These explorations should lead to improvements in lmi's physical design
(better encapsulation by groups of TUs, much as C++'s own facilities encourage
encapsulation at a lower level), which might also result in faster build times.

> GC> |  But I also thought of something else: we could also change the default
> GC> | visibility to hidden for the Unix builds.
[...]
> GC> Yes, someday we should do that, too.
> 
>  And would this day come before or after the one above it?

Before, after, or simultaneously would all be good.

> 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?

I don't think it matters which comes first or last.

>  Of course, comparing the build speed is going to be a bit difficult when
> one of them doesn't build wx_test

[...or product_files$(EXEEXT)...]

> 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?

No, sorry, I don't have a link.

>  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.
I have no concrete plan, so you be the judge.