[gccsdk] Something broken in trunk GCCSDK?

John Tytgat John.Tytgat at aaug.net
Thu Sep 9 16:32:01 PDT 2010


In message <f526415451.martin at bach.planiverse.com> you wrote:

> Last week-end I tried building an ARMv7-compatible Ghostscript 
> executable. To do so, I checked out the trunk GCCSDK, built a 
> cross-compiler (on openSuSE 11.2), which went smoothly and compiled 
> the vanilla Ghostscript 8.54 sources.
> 
> At first glance the resulting executable works (e.g., it renders PDF 
> files and converts PS to PDF fine), but it shows one striking oddity: 
> When you run it using
>   gs -h
> then it displays:
> Ghostscript 8.54<without a line feed, so the cursor remains here>
> 
> That behaviour is wrong. It is supposed to display the version date 
> after the number and many additional lines of help information.

Not good :-( Does <Esc> work ? <Alt><Break> ? <Ctrl>-G ?

It sounds like an output buffer flush problem.

> So, something has gone wrong in the porting process. The interesting 
> thing is that I then checked out an older revision of GCCSDK (I chose 
> rev4379), built the cross-compiler and recompiled the very same 
> Ghostscript sources. This resulted in a fully working executable that 
> displays the help information as it should.
> 
> So, I conclude that something must have become broken in trunk between 
> rev4379 and HEAD that causes this change of behaviour of the compiled 
> executable. There were several significant changes since then, not 
> least a switch from GCC 4.1.1 to 4.1.2, so the question is how we find 
> out what causes this problem. I can try and do some revision chopping 
> but this is a slow process because checking out the source tree and 
> building the cross compiler takes quite a while. So, I am wondering 
> whether anyone has an idea which change could have caused such an 
> effect. Has there been a change in output stream handling in Unixlib?

My first guess is indeed a possible regression (or latent bug now being
triggered) with UnixLib changes I made on 2 Jan 2010 and 21 Jan 2010 :
r4398 and r4459.

I'll try to reproduce this problem.

> BTW: I chose rev4379 because it corresponds to the RISC OS release GCC 
> 4.1.1 rel 2. I based this choice on the assumption that the state of 
> the GCC for RISC OS release should be a stable state of the GCCSDK 
> sources.

That's a correct assumption.  Thanks for the first feedback on gcc 4.1.2
code base :-)

John.
-- 
John Tytgat, in his comfy chair at home                                 BASS
John.Tytgat at aaug.net                             ARM powered, RISC OS driven




More information about the gcc mailing list