On 03/04/2013 05:36 PM, John Tytgat wrote:
In message
Ron wrote:
Setting UnixEnv$prog$sfix to "" is enough to turn off the sfix functioning.
For programs like tar that are acessing many files, I thought it might
also be be a speed advantage to remove the sfix /checking/ functions
In message
Ron wrote:
> In message
> John Tytgat wrote:
>
> > In message
> > Ron wrote:
> >
> > > Just my own approach, but I have built a !GCC that doesn't use suffix
> > > swapping and my recent build seems to be working OK.
> > > I also seem to have got away
In message
John Tytgat wrote:
> In message
> Ron wrote:
>
> > Just my own approach, but I have built a !GCC that doesn't use suffix
> > swapping and my recent build seems to be working OK.
> > I also seem to have got away with removing some suffixing routines from
> > the r
In message
Ron wrote:
> Just my own approach, but I have built a !GCC that doesn't use suffix
> swapping and my recent build seems to be working OK.
> I also seem to have got away with removing some suffixing routines from
> the recipe riscosify.c and unixify.c without side effects thi
In message
"Alan Buckley" wrote:
> From comments when I mentioned this bug on the ROOL forum it made me think
> Fat32FS does not increment the value as expected by the hack.
It's very much possible that this wrong assumption is the cause of your
problem.
However for enumeration purp
In message
"Alan Buckley" wrote:
>
> From comments when I mentioned this bug on the ROOL forum it made me think
> Fat32FS does not increment the value as expected by the hack.
>
> Is there anybody who could look at to confirm my findings (and possibly fix)
> this?
>
Just my own app
I’ve been trying to build a project stored on a Fat32FS USB pen drive and found
make wasn’t locating any of the files using the wildcard function. The wildcard
was looking for *.cc files so I believe it is to do with suffix swapping.
After further investigation I think I’ve tracked the problem d
