lmi
[Top][All Lists]
Advanced

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

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


From: Vadim Zeitlin
Subject: Re: [lmi] [Bulk] Re: Cross-compiling lmi from Linux to MSW
Date: Tue, 26 Jan 2016 16:07:25 +0100

On Tue, 26 Jan 2016 04:29:56 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2016-01-23 15:40, Vadim Zeitlin wrote:
GC> >
GC> >  I have a pending patch to lmi configure which adds flags for C++11
GC> > support, I can post it if you'd like. But until then you indeed need to
GC> > pass it configure manually, although I usually use it as part of CXX and
GC> > not CXXFLAGS to ensure that it's used also for linking. I don't actually
GC> > think it makes any difference under Linux, but it definitely does under OS
GC> > X (because C++11 uses a different standard library there) and so I just do
GC> > it consistency under all platforms.
GC> 
GC> Then for OSX, wouldn't it make sense to add it to LDFLAGS? Just curious.

 This works too, of course, but then you need to add it to two different
places instead of only one. And, to be incredibly pedantic, in principle
LDFLAGS could be used to link a C-only target, in which case -std=c++11
would be out of place (although almost certainly still harmless).

GC> Using CXX means writing the full compiler name everywhere:
GC>   CXX='i686-w64-mingw32-g++ -std=c++11'
GC> which doesn't seem like it ought to be necessary...so I tried adding
GC> '-std=c++11' to CXXFLAGS, and re-cross-compiling everything seems to work.

 Yes, this does work under Linux.

GC> But now here's something weird--could we need '-std=c++11' in CPPFLAGS?

 No, this would be a bad idea as it would be also used for compiling C code
then and, in the trunk lmi does have expm1.c (which doesn't exist in my
branch since many years... now I remember that getting rid of C sources was
also a motivation for using expm1 and log1p from boost).

GC> I configured lmi thus:
GC> 
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 -std=c++11'
GC> 
GC> and got:
GC> 
GC> checking wx/pdfdc.h usability... yes
GC> checking wx/pdfdc.h presence... no
GC> configure: WARNING: wx/pdfdc.h: accepted by the compiler, rejected by the 
preprocessor!
GC> configure: WARNING: wx/pdfdc.h: proceeding with the compiler's result
GC> checking for wx/pdfdc.h... yes

 This warning is harmless, as configure itself admits above, but, as I just
wrote in the boost::system thread, I have a patch avoiding it by skipping
the preprocessor check entirely which is the real solution for it.

 Regards,
VZ

reply via email to

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