Re: Right BCC version to use ?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello,

I am afraid moving the current build chain to another compiler is too ambitious... and selecting another "exotic" compiler would not bring us back into the mainstream...

Back to the initial question, I finally moved to your bin86/dev86 fork by cloning your GIT repository. I added a .gitignore to have a more clear view on "git status" when doing some changes, please find it attached as a patch proposal (big things start with little steps).

Regards,

MFLD


Le 24/03/2015 22:50, David Given a écrit :
On 24/03/15 12:30, Jody Bruchon wrote:
[...]
ELKS is tightly tied to BCC for now, so some future development will probably require changes to it. A big difference between BCC and GCC is that BCC includes a C library and headers whereas GCC is only a compiler and requires a C library to be built separately. That means I can't fix issues with the C library without bringing the whole thing along.
While I wouldn't suggest it for *new* development, because the compiler
technology is old and clunky and rather unmaintainable, but the ACK is
an ANSI C compiler suite which supports 8086 and comes with a full libc
--- this is what Minix used. It's even theoretically possible to run it
self-hosted on an ELKS-style machine, although it'd take work to recover
that ability these days. The 8086 coded generate isn't too bad. (Minix
was developed with it, after all.)

The downside is that it lives in its own little universe and doesn't
interoperate with anything; you have to use the ACK object file format
and the ACK linker etc. I believe it already supports Minix 16/16
segmented binaries.

The effort needed to persuade the ACK to produce ELKS executables is
probably quite small --- it already has partial support for ix86 and
m68k Linux; how different is the ELKS system call model? Making it build
the kernel is probably harder due to different dev86 and ACK linker magic.

This would only be worthwhile as a stopgap until 8086 gcc or pcc is
available, and it would need some careful evaluation of the code
quality, but it might be worth looking into.

The fairly elderly website is at: http://tack.sourceforge.net/


# .gitignore for DEV86
# Ignore output files

# Object and archive files

*.o
*.a

# Output directories

bin/
lib/

# Output files

ifdefg
include
make.fil

ar/ar.h
ar/ar86
ar/rel_aout.h

as/as86
as/as86_encap
as/version.h

bcc/bcc
bcc/bcc-cc1
bcc/ncc
bcc/version.h

bootblocks/version.h

copt/copt

cpp/bcc-cpp

ld/ar.h
ld/ld86
ld/objdump86
ld/version.h

libc/.config.dir
libc/.config.lst
libc/error/error_list.h
libc/i386sys/syscall.c
libc/i386sys/syscall.mak
libc/include/arch
libc/include/linuxmt
libc/include/malloc.h
libc/include/regexp.h
libc/include/regmagic.h
libc/include/stdio.h
libc/include/string.h
libc/syscall/call_tab.v
libc/syscall/defn_tab.v
libc/syscall/syscall.c
libc/syscall/syscall.dat
libc/syscall/syscall.mak

unproto/unproto

[Index of Archives]     [Kernel]     [Linux ia64]     [DCCP]     [Linux for ARM]     [Yosemite News]     [Linux SCSI]     [Linux Hams]

  Powered by Linux