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

[John Tytgat]

In message <5d2d2ac751.beeb at ron1954.woosh.co.nz>
          Ron <beeb at woosh.co.nz> wrote:

> In message <e0b88cc651.Jo at hobbes.bass-software.com>
>           John Tytgat <John.Tytgat at aaug.net> wrote:
> 
> > > After doing svn switch...
> > > and getting refreshed with the "updated to revision 5124" displayed.
> > > What are the correct steps to take to rebuild after this?
> > 
> > Best is to go for a full rebuild:
> > 
> >   $ make clean
> >   $ make
> > 
> > > Or does this just patch the already compiled cross directory?
> > 
> > No, a full rebuild is needed as this is a garantee we're using the same
> > set of sources.
> > 
> > Tbh, I'm still a bit mistified by this issue as I don't think we understand
> > what should have fixed this issue.
> > 
> > John.
> 
> Thanks, I needed to get that right before giving more reports.
> I have a directory 'b' containing some files and directory's 'a' and 'lib'.
> directory 'a' has directory 'c' and some files, directory 'c' contains an
> application.
> 
> 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.
-- 
John Tytgat, in his comfy chair at home                                 BASS
John.Tytgat at aaug.net                             ARM powered, RISC OS driven