[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lmi] Compiling takes longer with gcc-4.9.2
Re: [lmi] Compiling takes longer with gcc-4.9.2
Mon, 18 Jan 2016 15:32:43 +0100
On Mon, 18 Jan 2016 05:04:23 +0000 Greg Chicares <address@hidden> wrote:
GC> Strangely, OLD beats NEW for building wx and wxPdfDoc, with --jobs=8.
GC> Less strangely, NEW beats OLD for lmi makefile targets with --jobs=4;
GC> but it's still a bit strange that the difference is so small.
Yes, both are indeed pretty strange but...
GC> But what I really want to compare is cross compiling on x86_64-linux,
... it's this set of benchmarks that I'm most eager to see.
GC> > For the reference, the command used for building with Cygwin 4.9.2 was
GC> > make PATH=/opt/lmi/bin:/usr/i686-w64-mingw32/sys-root/mingw/bin:$PATH \
GC> > PATH_GCC=i686-w64-mingw32- LDFLAGS='' \
GC> > gcc_common_warnings='-Wall -Wno-unused-local-typedefs -Wno-parentheses
GC> > install check_physical_closure
GC> I dislike changing $PATH, but I believe I accomplished the same thing by
GC> specifying the full path to each binary in the toolchain, and copying
GC> the sys-root files to /opt/lmi/local/bin, which is on my $PATH.
This is cleaner when you are using the given version of the compiler, I
was doing it like this because it was simpler to switch between different
compilers like this.
GC> "LDFLAGS=''": I made "-Wl,--disable-auto-import" conditional on gcc-3.4.5,
GC> which I believe does what you intended.
GC> I added these warning flags:
GC> -Wno-conversion \
GC> -Wno-deprecated-declarations \
GC> -Wno-parentheses \
GC> -Wno-unused-local-typedefs \
GC> -Wno-unused-variable \
GC> I found '-Wno-deprecated-declarations' necessary for auto_ptr in xmlwrapp.
Notice that I've fixed this in the latest version of xmlwrapp at
https://github.com/vadz/xmlwrapp/, so all you need to do is to get rid of
this one is to update to the latest version (which doesn't have any
significant changes compared to the one being currently used as I wrote in
my cross-compiling post).
GC> I'm not sure why you didn't need '-Wno-conversion' as explained here:
Sorry, I forgot about this. And I still don't know why I didn't see it,
but I definitely didn't. Anyhow, as you write yourself at the URL above,
it's not a problem with C++11.
GC> > Notice that I had to reset LDFLAGS to avoid using
GC> > -Wl,--disable-auto-import option as the build failed with tons of linker
GC> > errors without this.
GC> Okay, that's what I guessed above. BTW, do you happen to know why
GC> MinGW-w64 seems to need this? IIRC, years ago libstdc++ didn't have
GC> the necessary decorations, but I should think they'd have had enough
GC> time to fix that by now.
I think adding the proper export declarations to the standard library may
be quite non-trivial but I didn't really look into this in details as from
my point of view the use of -Wl,--disable-auto-import was only necessary to
work around a bug in MinGw 3.4.5 anyhow, so I'm perfectly fine with just
not using it any more.
GC> > [*] The patch:
GC> > ---------------------------------- >8
GC> > diff --git a/install_wx.make b/install_wx.make
GC> > index 5b4cd0b..d359dc0 100644
GC> > --- a/install_wx.make
GC> > +++ b/install_wx.make
GC> > @@ -97,7 +97,7 @@ ggc_flags := --param ggc-min-expand=25 --param
GC> > config_options = \
GC> > --prefix=$(prefix) \
GC> > --build=i686-pc-cygwin \
GC> > - --host=i686-pc-mingw32 \
GC> > + --host=i686-w64-mingw32 \
GC> I had missed that. Got it now.
To answer your question about why it worked: you must have a MinGW Cygwin
cross-compiler installed too, don't you?
GC> > --disable-apple_ieee \
GC> > --disable-compat24 \
GC> > --disable-fswatcher \
GC> > @@ -118,6 +118,8 @@ config_options = \
GC> > --without-libjpeg \
GC> > --without-libtiff \
GC> > --without-subdirs \
GC> > +
GC> > +unused := FIXME-VZ \
GC> > AR='$(mingw_bin_dir)/ar' \
GC> > AS='$(mingw_bin_dir)/as' \
GC> > CC='$(mingw_bin_dir)/gcc $(ggc_flags)' \
GC> I'm disinclined to remove those. They're correct AFAICS, they're harmless,
GC> and they might be wanted someday.
I thought as much (which was why I just hacked them out instead of
removing them properly), but, FWIW, I still disagree: I think this is
unnecessary verbose (as always, the lines that don't exist are the only
ones certain to never contain any bugs) and potentially a source for
confusion, especially if another tool, not listed here, starts being used
later. But right now they're probably indeed harmless, if completely
Good luck with cross-compiling (but hopefully you won't need any luck to
make it work)!
Re: [lmi] Compiling takes longer with gcc-4.9.2, Greg Chicares, 2016/01/17
Re: [lmi] Compiling takes longer with gcc-4.9.2, Greg Chicares, 2016/01/18
- Re: [lmi] Compiling takes longer with gcc-4.9.2, (continued)
[lmi] KVM performance [Was: Compiling takes longer with gcc-4.9.2], Greg Chicares, 2016/01/24
Re: [lmi] [Bulk] KVM performance [Was: Compiling takes longer with gcc-4.9.2], Greg Chicares, 2016/01/25
[lmi] cgicc changes [Was: Compiling takes longer with gcc-4.9.2], Greg Chicares, 2016/01/18
- Re: [lmi] Compiling takes longer with gcc-4.9.2,
Vadim Zeitlin <=