[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Vadim Zeitlin
Subject: Re: [lmi] Cross-compiling lmi from Linux to MSW
Date: Fri, 22 Jan 2016 15:17:38 +0100

On Fri, 22 Jan 2016 04:26:10 +0000 Greg Chicares <address@hidden> wrote:

GC> mkdir ~/build/lmi-msw
GC> cd $_
GC> PATH=$HOME/msw/i686-w64-mingw32/bin:$PATH ~/src/lmi/configure \
GC>   --prefix=$HOME/msw/i686-w64-mingw32 --host=i686-w64-mingw32 \
GC>   CPPFLAGS=-I$HOME/msw/i686-w64-mingw32/include \
GC>   LDFLAGS=-L$HOME/msw/i686-w64-mingw32/lib \
GC>   CXXFLAGS='-Wno-unused-local-typedefs -Wno-unused-variable'
GC> This produces an error message:
GC> configure: error: Boost filesystem library boost_filesystem not found, use 
GC> if it is installed in non default location

 As usual, I'd really like to look at your config.log.

GC> We used this for xmlwrapp:
GC>       --with-boost=$HOME/msw/i686-w64-mingw32 \

 Yes, xmlwrapp is better written than lmi, I should use the same boost.m4
as Vaclav used for the former for the latter instead of redoing it, badly.

GC> ...so the error is impossible and, as a last resort, I re-read my
GC> command and saw the obvious
GC>   --with-boost-libs=dir=$HOME/msw/i686-w64-mingw32/ \
GC>                     ^^^^
GC> which validates the old usenet truism that if you write a problem
GC> report with meticulous rigor, half the time you won't have to send it.

 I think it was still worth sending it because something is wrong, it
should have worked without any extra options just because of CPPFLAGS and

GC>   i686-w64-mingw32-g++: error: unrecognized option '--enable-auto-import'
GC> Here's how I installed the cross toolchain:
GC>   apt-get install g++-mingw-w64-i686
GC> and let's see whether it's even remotely sane:
GC>   i686-w64-mingw32-gcc -dumpversion
GC>   4.6
GC> Okay, this is debian-7, so it's an older gcc, and maybe I should
GC> get 4.9.1 from debian-8 instead

 Yes, you definitely should. g++ 4.6 doesn't support C++11 (it supports
pieces of C++0x, but it's not at all the same thing) and it just doesn't
make sense to go back and try to work around its problems when we're trying
to standardize on using 4.9. Please don't waste time on trying to make it
work with 4.6.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]