Re: Our GCC-4.8 is broken

On 24/12/13 21:13, Cesar Strauss wrote:
> ... the output from "strings" is reduced to:
> 
>   $ strings gcc.exe | grep '[a-z]:/[a-z]'
>   i:/p/giaw/mingw/share/locale
>   i:/p/giaw/mingw/share/locale
> 
> Interestingly, these are Earnie's paths, not mine. This pointed to the 
> vector being some library built by Earnie and statically linked to my 
> gcc.exe. I found it by:
> 
> $ cd /mingw/lib; for f in *.a; do strings $f | grep '/share/locale' && 
> echo $f; done
> i:/p/giaw/mingw/share/locale
> i:/p/giaw/mingw/share/locale
> libintl.a
> 
> I avoided linking gcc to libintl by configuring gcc with --disable-nls. 
> This produced a build without any drive letters, which confirmed the 
> suspicion of libintl (gettext) being the vector.

Yes, I think we'd pretty much come to this conclusion, in the follow up
to bug #2108.

> The previous packaged version of gettext did not had this problem, so a 
> short term solution is to downgrade gettext and rebuild gcc and other 
> affected packages.
> 
> Afterwards, we should debug gettext to investigate why this regression 
> occurred and fix it.

FWIW, there were other issues with Earnie's packaging of gettext --
primarily improper (or no) segregation of DLLs -- leading to package
content conflicts in the upgrade/roll-back paths, which prompted me to
investigate further.  Unfortunately, at the time I was still running
GCC-3.4.5, so couldn't create a compatible build for our GCC-4 builds.
I got bogged down in cross-compiler build issues -- mostly originating
in Earnie's WSL.  I've now resolved those, so should be able to get back
to gettext soon after Christmas.

For now, sure, it makes sense to roll back to previous gettext, but it
would also be good if we can try my new build, when I have it ready, if
for no other reason than to confirm that my GCC-4.8 cross compiler is
generating compatible code for general release.

> It would also be nice to investigate the need for building gcc with 
> "identity mounts". Maybe it is due to a bad interaction between the gcc 
> build machinery and MSYS path translation.

That may be; I'll have to leave you to follow that up.  I may also
create an experimental crossed-native build of GCC-4.8 -- built on my
Linux host, for deployment on Win32, with Win32 target.

This would also be a good opportunity to create a build which doesn't
preclude building code for older processors; we should be building for
-march=i586, or maybe even -march=i386 -- see discussion thread:
http://thread.gmane.org/gmane.comp.gnu.mingw.user/43463

-- 
Regards,
Keith.

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk