ctime (and possibly asctime) pulls in 2.0+ strftime with -mcrt=nix13

[rvalles]

Using bebbo/amiga-gcc release "Mehchen".

test.c is just:

#include <time.h>
int main() {
    ctime((time_t*) 0);
}

When attempting to build it with -mcrt=nix13, it fails on linking:

$ /opt/amiga/bin/m68k-amigaos-gcc -mcrt=clib2 test.c #fine
$ /opt/amiga/bin/m68k-amigaos-gcc -mcrt=nix20 test.c #all good
$ /opt/amiga/bin/m68k-amigaos-gcc -mcrt=nix13 test.c
/opt/amiga/lib/gcc/m68k-amigaos/6.5.0b/../../../../m68k-amigaos/bin/ld: /opt/amiga/m68k-amigaos/libnix/lib/libnix.a(strftime.o): in function `strftime':
strftime.o:(.text+0x302): undefined reference to `__localevec'
/opt/amiga/lib/gcc/m68k-amigaos/6.5.0b/../../../../m68k-amigaos/bin/ld: strftime.o:(.text+0x34c): undefined reference to `__localevec'
/opt/amiga/lib/gcc/m68k-amigaos/6.5.0b/../../../../m68k-amigaos/bin/ld: strftime.o:(.text+0x3b2): undefined reference to `__localevec'
/opt/amiga/lib/gcc/m68k-amigaos/6.5.0b/../../../../m68k-amigaos/bin/ld: strftime.o:(.text+0x492): undefined reference to `__localevec'
/opt/amiga/lib/gcc/m68k-amigaos/6.5.0b/../../../../m68k-amigaos/bin/ld: strftime.o:(.text+0x4b4): undefined reference to `__localevec'
collect2: error: ld returned 1 exit status

Whereas a similar test, but calling strftime instead, does not exhibit this issue.

Therefore, somehow, ctime (and likely asctime too) is pulling 2.0+ version of strftime, despite crt13.

[bebbo]

please test

[rvalles]

Test program does now build and run on 3.1 with nix13.

It does, however, not work on 1.3 (demands utility.library, which doesn't exist for 1.3).

OTOH the program I was trying to build (gzip 1.2.4a), does now build and then runs on 3.2 with nix13, but that binary outright crashes on 1.3 (despite 32KB stack) with a 0..B guru (F line emulation).

All tests on A1200, with blizzard 1230mkIV (030+882@50 & 128M RAM), using blizkick for kick34.

[bebbo]

gzip 1.2.4a does build and run now - with the recent changes

[rvalles]

It does build with nix13 and runs properly on 3.x.

On 1.3, however:

It's close, but something's still off.

[bebbo]

My version is able to ungzip: gzip.gz

[rvalles]

I have now tested your binary:

I have no idea either. But I know I can't blame zshell.

[bebbo]

it's the drive/volume RAM:

[rvalles]

No dice.

[bebbo]

gzip.gz

please test

[rvalles]

Now it runs, somewhat. It can compress and decompress a small file (used s:startup-sequence).

But it seems to have trouble with a larger one:

[rvalles@yukino pyamigadebug]$ gunzip asmtwo.gz

gzip: asmtwo.gz: invalid compressed data--crc error

gzip: asmtwo.gz: invalid compressed data--length error
[rvalles@yukino pyamigadebug]$ file asmtwo.gz
asmtwo.gz: gzip compressed data, was "asmtwo", last modified: Tue Nov  7 13:12:04 2000, from Amiga, original size modulo 2^32 97312

[bebbo]

sorry - that is beyond the scope here. But I noticed that there is a fixed version on Aminet which mentions some bug in match.S.

[rvalles]

sorry - that is beyond the scope here. But I noticed that there is a fixed version on Aminet which mentions some bug in match.S.

I'll rebuild the toolchain now; I do build my gzip w/o match.S (because I can't be bothered to use the .a in the tarball... and I guess it's bad after all), then the c version is used.

I'll let you know how that goes.

[rvalles]

Yep. The one I built (not using match.S at all) is good.

I can now crunch and decrunch that same file w/o issue.