Re: NetBSD 9.3 and Amiga loadbsd

[Roc Vallès <vallesroc%gmail.com@localhost>]

Hi Frank Wille,

You're very welcome. Thank you for your comments.

Maybe that 2.95.3 (i.e. ancient) gcc is ok with this:
https://github.com/rvalles/netbsd_amiga_loadbsd_pleasebuild/commit/fefe1fe2b1d1a9bdb06c97aeb11398f07a096a51

The gcc I'm using is a bit newer, and I'm also cross compiling loadbsd
(on Linux) rather than building it on the Amiga itself. I do most of
my Amiga development crossdev, and never had gcc in AmigaOS (i.e.
outside of netbsd).

$ /opt/amiga/bin/m68k-amigaos-gcc --version
m68k-amigaos-gcc (GCC) 6.5.0b 210329062916

It is a little newer, and comes from the bebbo/amiga-gcc
cross-toolchain. The sources I am based on are those from netbsd
itself (no patches other than mine). I didn't really care about
warnings, just about making it build. I incorporated files as needed,
removing code instead if I could get away with it (to minimize
dependencies). That's likely how I never included that err.h.

Is your loadbsd.o an actual amiga hunk binary, somehow built from
netbsd? Is this some ancient crossdev toolchain (amigaos target, in
netbsd)? Where do you get the relevant AmigaOS headers from?

Note that ultimately, what I'm trying to achieve is for netbsd to
distribute a binary that has the serial console flag working, so that
users in general can use it to e.g. install netbsd from the serial
console. It ultimately does not matter where it comes from. My build
effort was after being told on IRC that the reason the binary was
outdated was that nobody was currently able to build it, so I simply
solved that problem at the time. Only somebody who has access can
update the distributed binary with a current one; I don't have access.

Regards,
Roc


On Sat, 27 Aug 2022 at 19:46, Frank Wille <frank%phoenix.owl.de@localhost> wrote:
>
> Roc Vallès wrote:
>
> > does not support the flag for using the serial port
> > as console. Dug a little deeper by asking around (on IRC), and I found
> > the reason is that nobody had built it for years (to the point of
> > syntax errors sleeping undetected for years in the main C source
> > file),
>
> I have a LoadBSD 3.1 (with latest patches from Gunther Nikl) sitting on my
> A3000's hard disk, which I successfully compiled with gcc V2.95.3 in 2015.
>
> Just repeated the compilation today, and there is not a single warning.
>
>
> > I did manage to coerce it to build and make it so others can build it,
> > too: https://github.com/rvalles/netbsd_amiga_loadbsd_pleasebuild
>
> This one doesn't build with my A3000's gcc-installation:
>
> gcc -m68020 -Wa,-m68030 -D_STANDALONE -I./include -O2 -fomit-frame-pointer
> -msmall-code   -c loadbsd.c -o loadbsd.o
> In file included from loadbsd.c:50:
> include/inttypes.h:6: warning: useless keyword or type name in empty
> declaration
> include/inttypes.h:6: warning: empty declaration
> include/inttypes.h:7: warning: useless keyword or type name in empty
> declaration
> include/inttypes.h:7: warning: empty declaration
> include/inttypes.h:8: warning: useless keyword or type name in empty
> declaration
> include/inttypes.h:8: warning: empty declaration
> include/inttypes.h:9: warning: useless keyword or type name in empty
> declaration
> include/inttypes.h:9: warning: empty declaration
> loadbsd.c: In function `_Vdomessage':
> loadbsd.c:893: parse error before `85'
> loadbsd.c: At top level:
> loadbsd.c:907: warning: type mismatch with previous implicit declaration
> loadbsd.c:598: warning: previous implicit declaration of `err'
> loadbsd.c:907: warning: `err' was previously implicitly declared to return
> `int'
>
>
> 1. The inttypes.h warnings are caused by the double definition of uint8_t,
> uint16_t, etc., in your local inttypes.h. Don't know why your compiler
> doesn't define these types with <sys/types.h> - even V2.95.3 did.
>
> 2. The parse error in line 893 is caused by
>     int sys_nerr = 0; //FIXME
> Not sure why you added that line. Maybe because your removed <err.h>?
> Deleting it fixes the error for me, but it might be better to remove lines
> 899-901 instead, in case you had problems with sys_nerr?
>
> 3. If you delete the include for <err.h>, then there is no prototype for
> err(), which causes the following warnings (907,598). Solution: add the
> prototype on top of the source, or move the err-function before main().
>
> --
> Frank Wille
>