Re: [lmi] Cross-compiling lmi from Linux to MSW

[Greg Chicares]

On 2016-01-14 01:35, Vadim Zeitlin wrote:
[...]
> This was the most complicated part. The really aggravating thing is that I
> could cross-compile the latest 1.60 version without too many problems: for
> the future reference (and because I don't know whether this is really
> documented anywhere, at least I didn't find anything else than indirect
> references), let me just note that you need to do
> 
>       $ echo 'using gcc : mingw : i686-w64-mingw32-g++ ;' > ~/user-config.jam
> 
> and then you can build bjam and run
> 
>       $ ./tools/build/src/engine/bin.linuxx86_64/b2 \
>           toolset=i686-w64-mingw32 target-os=windows filesystem regex

Could we not live with 1.49.0.1 here:
  https://packages.debian.org/wheezy/libboost-all-dev
if we actuallyneed to upgrade this thing? It's a useful library, but its
build system is painful. Alternatively, we could pick any version we like
and build what we need manually:

> to build the libraries. However with the 1.38 version used by lmi currently
> I couldn't find any way to do it and the ancient version of bjam used in it
> doesn't seem to have had any documentation at all or, at least, it's
> impossible to find it by now. Also, using bjam2 with boost 1.38 doesn't
> work neither. So I ended up just compiling everything manually which is

As noted in lmi's 'objects.make':

# As for listing the object files here, the regex author says:
#   http://groups.google.com/group/boost-list/msg/7f925ca50d69384b
# | add the libs/regex/src/*.cpp files to your project

> Notice that the commands above do _not_ use "-std=c++11" for compiling for
> the good reason that Boost 1.38 doesn't build with this option (there are
> many, many errors due to the fact that this old version used pre-standard
> support for things like rvalue references which worked differently from the
> real C++11, so there is really no chance of fixing this). Because of this I
> couldn't make things compile in C++11 mode for now, we absolutely have to
> update Boost for this.

Yet it does seem to compile natively in msw with '-std=c++11',
so isn't it really strange that the cross-compiler fails?

And IIRC they changed the 'filesystem' design in some deep way, so
"upgrading" that means a big lmi rewrite. Can we just wall that off
into a library of its own and build it separately, using 1.38 forever?

The only other not-all-headers boost library we use is 'regex',
and that seems to be provided by gcc now that it's a standard:
  i686-w64-mingw32/include/c++/regex
If we switch 'regex' to the system library, then 'filesystem' is our
only headache. If we sequester 'filesystem' in its 1.38 version, then
we can upgrade boost easily any time, right? Nothing to build, so no
dependency on any particular debian release--it's all just headers
that we can download from boost.

> I downloaded the version used in install_libxml2_libxslt.make:

[...snip beaucoup...]

Perhaps we should upgrade these xmlsoft.org libraries now.

> We're currently using xmlwrapp 0.7.1 but there are a couple of problems
> preventing it from being easily cross-compiled, in particular it requires a
> couple of Boost library that we don't otherwise use.

/opt/lmi/third_party[0]$grep 'include.*boost' include/x*/**/* src/lib*/**/*
src/libxml/pimpl_base.h:    #include <boost/pool/singleton_pool.hpp>

But that must be a headers-only library, because the msw-native lmi
build has always worked and continues to work, right? And thus...

> It would be possible
> to build these libraries just for it,

...what boost libraries would need to be built? What am I missing here?

> but considering that I also wanted to
> fix the warnings about the use of std::auto_ptr<> in it, I decided to use
> the latest git version instead. While I understand that you want to avoid
> changing more than one thing at once, in this particular case I think the
> change is very safe as there are no changes in the sources whatsoever
> between 0.7.1 and the latest master of xmlwrapp, only a couple of additions
> which don't affect lmi use of it.

Now that we have the compiler working, this may be the perfect time to
update the xmlsoft.org libraries. And normally I'd say that updating
xmlwrapp is one of the easiest and safest upgrades we can make. I'm just
worried about whatever instability is injected through boost--boost is
beginning to feel like systemd.

> wxWidgets
> ---------
> 
> This one was the simplest.

That's no surprise. But, after the foregoing, it is a relief.

> lmi itself (finally!)
> ---------------------
> 
> After all the struggles with the dependencies, this one was pretty simple.
> However some changes were still required: first, I'd like to commit a patch
> removing the code unconditionally appending "mgw" suffix to the Boost
> libraries when building using MinGW compiler from configure, it's always
> possible to specify it explicitly using --with-boost-toolkit option, but
> it's impossible to specify it as being empty using it.

Committed 20160121T0045Z, revision 6487.

> Second, we need to
> add the "force linking" stuff to alert_wx.cpp and main_wx.cpp to ensure
> that the alert function pointers are set correctly in lmi_wx.exe as
> otherwise they were not, resulting in an error message and abort, for the
> same reason as in the MSVS build: alert_wx object file was simply omitted
> entirely by the linker.

Committed (with additions) 20160121T0032Z,  revision 6486.