lmi
[Top][All Lists]
Advanced

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

Re: [lmi] Compiling takes longer with gcc-4.9.2


From: Vadim Zeitlin
Subject: Re: [lmi] Compiling takes longer with gcc-4.9.2
Date: Tue, 19 Jan 2016 01:48:25 +0100

On Mon, 18 Jan 2016 22:36:06 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2016-01-18 14:32, Vadim Zeitlin wrote:
GC> > On Mon, 18 Jan 2016 05:04:23 +0000 Greg Chicares <address@hidden> wrote:
GC> > 
GC> > GC> >  For the reference, the command used for building with Cygwin 4.9.2 
was
GC> > GC> > 
GC> > GC> > make 
PATH=/opt/lmi/bin:/usr/i686-w64-mingw32/sys-root/mingw/bin:$PATH \
GC> > GC> > PATH_GCC=i686-w64-mingw32- LDFLAGS='' \
GC> > GC> > gcc_common_warnings='-Wall -Wno-unused-local-typedefs 
-Wno-parentheses -Wno-unused-variable' \
GC> > GC> > install check_physical_closure
GC> > GC> 
GC> > GC> I dislike changing $PATH, but I believe I accomplished the same thing 
by
GC> > GC> specifying the full path to each binary in the toolchain, and copying
GC> > GC> the sys-root files to /opt/lmi/local/bin, which is on my $PATH.
GC> > 
GC> >  This is cleaner when you are using the given version of the compiler, I
GC> > was doing it like this because it was simpler to switch between different
GC> > compilers like this.
GC> 
GC> Understood. BTW, once we go into production with gcc-4.9.2, I intend to 
remove
GC> gcc-3.4.5 support forever

 This is great to hear as otherwise I'd still have to check compilation of
all my patches with that compiler and I'd really rather get rid of it.

GC> > GC> I'm not sure why you didn't need '-Wno-conversion' as explained here:
GC> > GC>   http://lists.nongnu.org/archive/html/lmi/2015-12/msg00028.html
GC> > 
GC> >  Sorry, I forgot about this. And I still don't know why I didn't see it,
GC> > but I definitely didn't. Anyhow, as you write yourself at the URL above,
GC> > it's not a problem with C++11.
GC> 
GC> I'm confused: I don't see where I said that.

 Sorry, you didn't, I've somehow confused -Wno-conversion with the error
mentioned in the beginning of the above message. I'll need to recheck if I
couldn't have used a wrong version of Boost because this does seem very
suspicious. And sorry again for confusing myself badly enough to even
confuse you.

GC> > GC> >  config_options = \
GC> > GC> >    --prefix=$(prefix) \
GC> > GC> >    --build=i686-pc-cygwin \
GC> > GC> > -  --host=i686-pc-mingw32 \
GC> > GC> > +  --host=i686-w64-mingw32 \
GC> > GC> 
GC> > GC> I had missed that. Got it now.
GC> > 
GC> >  To answer your question about why it worked: you must have a MinGW Cygwin
GC> > cross-compiler installed too, don't you?
GC> 
GC> No. I have only what lmi's 'install_cygwin.bat' provides:

 Thinking more about this, I don't actually know what is the --host option
value used for if you explicitly redefine the values of all the build tools
(i.e. AR, CC, CXX, LD, ...). Maybe it actually doesn't matter what it is in
this case as long as it's different from the "build" string?

GC> Or is it supposed to disregard an incorrect '--host' specification and
GC> just DWIM?

 I don't know. Normally a wrong host value would quickly result in a
failure because configure wouldn't be able to find a working ${host}-gcc,
but this doesn't happen in our case, of course...

 Regards,
VZ

reply via email to

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