Leffmann's headers and config files don't help, because the problem is in the vbcc binary.
I have no idea what went wrong. I studied the build logs and all seems normal. The warnings are harmless. The data types are correct.
It is either caused by LLVM or its settings. Does it use a strange char-type or encoding? Is "char" signed or unsigned? Can you switch to GCC or a different compiler somehow?
@Leffmann: Did you also build vbcc with LLVM? Which version? Maybe you can provide your "vbccm68k" binary for testing?
Otherwise, if you are really desparate and willing to find the problem: I saw that you compiled vbccm68k with source level debugging (-g) and without optimization. You could try to debug this strange macro definition, if you have a working GDB or similar. For example, set a break point at "define_macro":
Code:
frank@altair gdb /usr/local/vbcc/bin/vbccm68k
GNU gdb (GDB) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
(...)
Reading symbols from /usr/local/vbcc/bin/vbccm68k...done.
(gdb) b define_macro
Breakpoint 1 at 0x18a7b08: file ucpp/macro.c, line 1632.
(gdb) r -hunkdebug "nada.c" -o= "tmp0.asm" -c99 -O=1 -no-cpp-warn -I/opt/vbcc/targets/m68k-kick13/include/
Starting program: /usr/local/vbcc/bin/vbccm68k -hunkdebug "nada.c" -o= "tmp0.asm" -c99 -O=1 -no-cpp-warn -I/opt/vbcc/targets/m68k-kick13/include/
vbcc V0.9f (c) in 1995-2017 by Volker Barthelmann
vbcc code-generator for m68k/ColdFire V1.12 (c) in 1995-2017 by Volker Barthelmann
Breakpoint 1, define_macro (ls=0x18e30fc <ls>,
def=0x18b9600 "__section(x)=__vattr(\"section(\"#x\")\")")
at ucpp/macro.c:1632
1632 char *c = sdup(def), *d;
(gdb)
"def" shows the macro definition on each breakpoint. This debugging session was on an iBook G4 running NetBSD, but should be similar.
EDIT: 'c' continues the program, until next break point.