Re: [gccsdk] build zip failure

In message <9507210c53.beeb@ron1954.woosh.co.nz>
Ron <beeb@woosh.co.nz> wrote:

> In message <07ad160c53.Jo@hobbes.bass-software.com>
> John Tytgat <John.Tytgat@aaug.net> wrote:
>
> > In message <70fbce0b53.beeb@ron1954.woosh.co.nz>
> > Ron <beeb@woosh.co.nz> wrote:
> >
> > > In message <89c5080b53.Jo@hobbes.bass-software.com>
> > > John Tytgat <John.Tytgat@aaug.net> wrote:
> > >
> > > > In message <177cd20a53.beeb@ron1954.woosh.co.nz>
> > > > Ron <beeb@woosh.co.nz> wrote:
> > > >
> > > > > The only autobuilder build I have done is zip which has failed in the
> > > > > later stage with
> > > > >
> > > > > mv: cannot stat '../zip30-joty/acorn/swiven.c': No such file or directory
> > > > >
> > > > > There is a ../zip30 directory there, but not the above.
> > > >
> > > > I could reproduce this. This is because of r5221 by Chris Gransden which
> > > > I fail to understand why there was a 'mv' added as part of that change.
> > > > Chris, any idea why that was needed ?
> > > >
> > > > After removing that 'mv' (in r6249) and fixing a couple of other
> > > > Autobuilder bugs (r6248 and r6250), I got a zip RiscPkg package built.
> > > >
> > > > John.
> > >
> > > I'm now 'At revision 6250' and still get the error,
> >
> > Which error do you mean with "the error", the original
> > "mv: cannot stat '../zip30-joty/acorn/swiven.c': No such file or directory"
> > one ?
>
> Yes, no change. I deleted everything in the build(s) directory before
> re-running build zip, I think that is clean enough.

I believe you didn't do svn update for the autobuilder directory (where
the fixes were made), perhaps you did that for gcc4 directory ?

> > > but looking back up
> > > the terminal, there is an error trying to open *.orig.tar.bz2
> > >
> > > 2013-01-10 22:21:18 URL:http://ftp.uk.debian.org/debian/pool/main/z/zip/zip_3.0-6.debian.tar.gz [7132/7132] -> "zip_3.0-6.debian.tar.gz" [1]
> > > tar (child): *.orig.tar.bz2: Cannot open: No such file or directory
> > > tar (child): Error is not recoverable: exiting now
> >
> > I see the same think in my last-success log file for 'zip'. It looks
> > like this error gets ignored as the build continues and succeeds making
> > the final package (not that I fully understand why this can happen).
> >
> > John.
>
> Yes, I noticed later in the failure file, that it does this (incase of?)
> for a .xz and .bz2 instance.
> As you say, that looks like that is always done, so shouldn't be a problem.
> Could it be something related to the CWD?

Not sure what you're hinting at. The thing which bothers me there is that
error return value of processes in those build scripts get ignored.
That's sloppy and recipe for lot of frustration.

> Digressing here:
> 'Cant stat' is usually a missing file or a file name misunderstanding.
> I have just found that parsing a directory name with slashes to my
> RISC OS tar gives this error.
> I have now modified my directory leafname extraction routine to swap
> "." and "/" around also.
> Chris's tesseract port works well with full RISC OS paths if I run them
> through my swap routine and is probably the case for most ports
> unless the argument parsing is modified in the source.
> Modifying may be easy sometimes, but other times the source might
> want to detect particular extensions so it can get complicated.
>
> Generally we always feed the unix ports unix names and the unix port
> outputs RISC OS names which is a simple rule to remember anyway.

Feel free to develop your own Unix -> RISC OS path translation code, but
why not use UnixLib's __riscosify() (unixlib/local.h) instead ?

John.
--
John Tytgat, in his comfy chair at home
John.Tytgat@aaug.net

_______________________________________________
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