[gccsdk] [Bug 218] __riscosify_control is not taken into account when using UnixLib as shared library

Ron beeb at woosh.co.nz
Thu Apr 28 16:25:30 PDT 2011


In message <c4c5baca51.Jo at hobbes.bass-software.com>
          John Tytgat <John.Tytgat at aaug.net> wrote:

> In message <5d2d2ac751.beeb at ron1954.woosh.co.nz>
>           Ron <beeb at woosh.co.nz> wrote:
> 
<snip>
> > 
> > Tar will make the archive fine, It uses __RISCOSIFY_NO_REVERSE_SUFFIX
> > and  __RISCOSIFY_FILETYPE_EXT to do this.
> > The archive opens with Spark and everything is in place.
> > 
> > When reversing the process using tar I get directories 'b' and 'b/a'
> > and errors, unless I set unixenv$sfix "".
> > So no, I dont have __RISCOSIFY_NO_SUFFIX doing it's job here.
> 
> I'm confused.  You're claiming __RISCOSIFY_NO_SUFFIX not doing its job
> but you also say you're only specifying  __RISCOSIFY_NO_REVERSE_SUFFIX
> and __RISCOSIFY_FILETYPE_EXT ?
> 
> John.
I'm using

#include <unixlib/local.h>
int __riscosify_control=__RISCOSIFY_NO_SUFFIX|__RISCOSIFY_NO_REV
ERSE_SUFFIX|__RISCOSIFY_FILETYPE_EXT;

but including or excluding __RISCOSIFY_NO_SUFFIX makes no difference.

The fact that the latter two are working makes me think that it
is the flags variable that is not showing the 0x0100 bit properly
for masking in riscosify.c

I haven't worked out riscosify completely yet.

I did a fresh build on a separate ubuntu partition after the last
svn update but still got the same result.

Thanks, Ron M. 




More information about the gcc mailing list