In message <f526415451.mar...@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.tyt...@aaug.net ARM powered, RISC OS driven _______________________________________________ GCCSDK mailing list gcc@gccsdk.riscos.info Bugzilla: http://www.riscos.info/bugzilla/index.cgi List Info: http://www.riscos.info/mailman/listinfo/gcc Main Page: http://www.riscos.info/index.php/GCCSDK
