[lmi] Native lmi build under Linux

[Vadim Zeitlin]

 Hello,

 I've realized that if you're working on native lmi build right now you're
probably going to duplicate the number of changes already done in

        https://github.com/vadz/lmi/pull/158

 This PR changes .github/workflows/ci.yml file that you're not interested
in (although perhaps you might be... e.g. IMO LD_LIBRARY_PATH should be
handled by lmi makefiles themselves instead of by doing it in this script)
but it also changes a lot of other files. I'm not sure if there is some way
of defining LMI_SO so that it could occur after the function return type,
but I don't think so: this works when it's defined as __declspec(dllfoo),
but the visibility attribute can't occur in the middle of a declaration,
AFAIK.

 Of course, maybe you're not actually testing build_type=so_test and in
this case your build should work without all these LMI_SO changes. However
you may still need some of the other ones, already done in this PR. E.g.
you can see that Ilya omits --host option when not cross-compiling, which
does indeed solve the issue with wxWidgets you've encountered, as I thought
it would.

 Then there is also the change to set_toolchain.sh which is, IMO, not
correct as it's written right now, but this file still needs to be changed
to avoid using Wine for native builds. And, related to this, I wonder what
do you think about the changes to test_coding_rules_test.sh which look good
to me, i.e. it seems to be better to reuse set_toolchain.sh in this script
rather than partially duplicate it, but perhaps you had some reason not to
do it that I'm not aware about?

 Again, I don't want to distract you from the other tasks you're working
on, but I'm just afraid that you're going to run into all the same problems
that Ilya has already fixed. And even if you don't agree with his fixes
(and as you can see from the comments I left there, even I don't agree with
all of them), it should hopefully be still useful at least to see his
solutions to these problems, even if you decide to do something different
about them.

 Ideally I'd really like to:

1. Apply the minimal fixes to make the simple (i.e. without LMI_SO) build
   work under Linux out of the box.
2. Apply my upcoming PRs moving third party libraries to submodules (and
   updating them).
3. Apply the big, but trivial, patch fixing LMI_SO locations and allowing
   build_type=so_test to work under Linux too.

 What do you think?
VZ

pgp797JKeKfio.pgp
Description: PGP signature