[gccsdk] [Bug 218] __riscosify_control is not taken into account when using UnixLib as shared library
John.Tytgat at aaug.net
Wed Apr 27 16:31:29 PDT 2011
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
> 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 Tytgat, in his comfy chair at home BASS
John.Tytgat at aaug.net ARM powered, RISC OS driven
More information about the gcc