Wasting time doing more “research” on old GCC, and thanks to suggestions I thought that in addition to the old 1.x stuff, but I should include my old favorite 2.5.8, and the stalled 2.7.2.3, and the EGCS Pentium improved GCC fork. I figured re-treading on old ground with the xMach/OSKit build on x86_64 should be safe/quick & easy.
My cross chain fails when trying to build libgcc.a How annoying but I already have one, so I bypass it, and GCC then tries to build the crt (c runtime library startup code) and that fails too!
../binutils-990818-bulid/gas/as-new crtstuff.S -o crtstuff.o
Segmentation fault
I’m using GCC 12.2.0 on Debian 12. Ok maybe I’ve finally hit drift, so let me try some other binutils. binutils-2.10.1, binutils-2.14. I had originally been lying saying I’m a Dec Alpha running either OSF or Linux as it matches the size & endian alignment, but no dice. I found out about the ‘linux32’ command that’ll fake it’s environment as an i686 processor to fake out a lot of builds. But the same result over and over. So, I break down and fire up GDB.
(gdb) r
Starting program: /root/src/xmach/binutils-2.14-bulid/gas/as-new crtstuff.S -o crtstuff.o
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Program received signal SIGSEGV, Segmentation fault.
0x0000555555592ef0 in md_estimate_size_before_relax (fragP=fragP@entry=0x555555668fa8, segment=segment@entry=0x555555668730) at ../../binutils-2.14/gas/config/tc-i386.c:4441
4441 return md_relax_table[fragP->fr_subtype]->rlx_length;
(gdb) bt
#0 0x0000555555592ef0 in md_estimate_size_before_relax (fragP=fragP@entry=0x555555668fa8, segment=segment@entry=0x555555668730) at ../../binutils-2.14/gas/config/tc-i386.c:4441
#1 0x000055555558bce2 in relax_segment (segment_frag_root=0x555555668f30, segment=segment@entry=0x555555668730) at ../../binutils-2.14/gas/write.c:2266
#2 0x000055555558c39c in relax_seg (abfd=<optimized out>, sec=0x555555668730, xxx=0x7fffffffe960) at ../../binutils-2.14/gas/write.c:659
#3 0x000055555559b01f in bfd_map_over_sections (abfd=0x55555565e030, operation=operation@entry=0x55555558c370 <relax_seg>, user_storage=user_storage@entry=0x7fffffffe960)
at ../../binutils-2.14/bfd/section.c:1101
#4 0x000055555558b501 in write_object_file () at ../../binutils-2.14/gas/write.c:1565
#5 0x000055555556e288 in main (argc=2, argv=0x5555556302d0) at ../../binutils-2.14/gas/as.c:924
(gdb) quit
The whole issue revolves around md_relax_table! I’d seen a ‘fix’ where you add in a pointer, and it’ll satisfy GCC and sure it’ll compile. Years ago, I had #ifdef’d it out until when I needed it, but the real answer is to embrace 1989 and set the compiler flags to “-std=gnu89”
I can’t help but think at some point soon 1989 will be removed as it’s only wierdos like me building this stuff.
Just as the old Unix error status of sys_nerr has been removed for ‘reasons’ so may as well amputate all the old code:
- if (e > 0 && e < sys_nerr)
- return sys_errlist[e];
Nothing much you can do about it, Linux isn’t trying to be Unix anymore.
64/32
In the end it doesn’t seem to matter. OSkit fails to build:
i586-linux-gcc -c -o base_multiboot_init_cmdline.o -MD -DHAVE_CONFIG_H -DOSKIT_X86 -DOSKIT_X86_PC -DINDIRECT_OSENV=1 -I. -I../../oskit-20020317/kern/x86 -I../../oskit-20020317/kern/x86/pc -I../../oskit-20020317/kern/x86/dos -I../../oskit-20020317/kern -I- -I../../oskit-20020317/oskit/c -I.. -I../../oskit-20020317 -nostdinc -Wall -O2 -g ../../oskit-20020317/kern/x86/pc/base_multiboot_init_cmdline.c
i586-linux-gcc: Internal compiler error: program cc1 got fatal signal 11
make[1]: *** [../../oskit-20020317/GNUmakerules:124: base_multiboot_init_cmdline.o] Error 1
And surprisingly mig does build, but Mach does not.
i586-linux-gcc -c -MD -DLINUX_DEV=1 -DHAVE_VPRINTF=1 -DHAVE_STRERROR=1 -Di386 -DMACH -DCMU -I- -I. -I../../../kernel/libmach/standalone -I../../../kernel/libmach/c -I../../../kernel/libmach -I/root/src/xmach/xMach/object-kern/libmach -I/root/src/xmach/xMach/object-kern/../kernel/generic/libmach/standalone -I/root/src/xmach/xMach/object-kern/../kernel/generic/libmach/c -I/root/src/xmach/xMach/object-kern/../kernel/generic/libmach -I../../../kernel/include/mach/sa -I../../../kernel/include -I/root/src/xmach/xMach/object-kern/../kernel/generic/include -I/root/src/xmach/xMach/object-kern/include -I/root/src/xmach/xMach/object-kern/../kernel/generic/include/mach/sa -nostdinc -O1 /root/src/xmach/xMach/object-kern/libmach/bootstrap_server.c
/root/src/xmach/xMach/object-kern/libmach/bootstrap_server.c: In function `_Xbootstrap_privileged_ports':
/root/src/xmach/xMach/object-kern/libmach/bootstrap_server.c:90: `null' undeclared (first use this function)
/root/src/xmach/xMach/object-kern/libmach/bootstrap_server.c:90: (Each undeclared identifier is reported only once
/root/src/xmach/xMach/object-kern/libmach/bootstrap_server.c:90: for each function it appears in.)
Needless to say, this is why I don’t use OS X anymore. Not having a 32bit userland basically killed it for me.
I guess the next step is to go ahead with qemu-user mode wrappers to fake it.
Sorry if you were hoping for some great conclusion.