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: Sat, 23 Jan 2016 16:40:11 +0100

On Sat, 23 Jan 2016 06:44:31 +0000 Greg Chicares <address@hidden> wrote:

GC> First of all [not in attachment because this command succeeded]:
GC>     CXX    liblmi_la-authenticity.lo
GC> 'make' output from some other autotoolized packages shows actual commands;
GC> is there a way to see the same thing here?

 Yes, "make V=1" will show it, see https://autotools.io/automake/silent.html
I rather like the "silent" display by default but I agree that it would be
nice if it could be somehow made to output "rerun the command with V=1 to
see more details" in case of make failure.

GC> That would help here:
GC> 
GC>   CXXLD    lmi_cli.exe
GC> libtool: link: Could not determine the host path corresponding to
GC> libtool: link:   `/home/greg/msw/i686-w64-mingw32/lib'
GC> libtool: link: Continuing, but uninstalled executables may not work.
GC> libtool: link: Could not determine the host path corresponding to
GC> libtool: link:   
`/home/greg/msw/i686-w64-mingw32/lib:/home/greg/msw/i686-w64-mingw32/bin'
GC> libtool: link: Continuing, but uninstalled executables may not work.

 AFAIK these warnings are harmless and they also seem to be unavoidable.

GC> ./.libs/lt-lmi_cli.c:39:5: error: '_putenv' redeclared without dllimport 
attribute: previous dllimport ignored [-Werror=attributes]
GC>  int _putenv (const char *);
GC>      ^

 Oops, sorry, have I really forgotten to mention this in my email? I was
definitely going to speak about this but apparently sent my email too soon,
as usual :-( Sorry!

GC> I don't know exactly what it's trying to do, so it's hard to debug.
GC> AFAICT, the "Could not determine the host path" part is innocuous.
GC> But where does the '_putenv' warning come from? I don't find any
GC> '_putenv' call in lmi, which doesn't have any 'lt-lmi_cli.c' file
GC> (and has very few '.c' files at all). Is libtool actually writing
GC> a C program to invoke the linker?

 Yes, exactly.

GC> and...oh, no!...the first result is a message from you:
GC>   https://lists.gnu.org/archive/html/libtool/2011-06/msg00037.html
GC> And you're talking about a project that still used gcc-3.4.5 in 2011,
GC> and insists on using '-Werror'. (I bet it uses '-pedantic', too.)
GC> Then the only response you get is from yourself. Should I now look
GC> for your patch and apply it?

 Yes, please see https://savannah.gnu.org/patch/?8843

GC> BTW, changing the subject, I configured 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' 2>&1 |less
GC> 
GC> so to get C++11 am I supposed to add '-std=c++11' to CXXFLAGS?
GC> If so, should I do that to every 'configure' command and then
GC> rebuild every library (except libxml2 and libxslt, which are
GC> just plain C)?

 I have a pending patch to lmi configure which adds flags for C++11
support, I can post it if you'd like. But until then you indeed need to
pass it configure manually, although I usually use it as part of CXX and
not CXXFLAGS to ensure that it's used also for linking. I don't actually
think it makes any difference under Linux, but it definitely does under OS
X (because C++11 uses a different standard library there) and so I just do
it consistency under all platforms.

 Regards,
VZ

reply via email to

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