[gccsdk] Something broken in trunk GCCSDK?
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
That's a correct assumption. Thanks for the first feedback on gcc 4.1.2
code base :-)
John Tytgat, in his comfy chair at home BASS
John.Tytgat at aaug.net ARM powered, RISC OS driven
More information about the gcc