Re: Right BCC version to use ?

[MFLD <mfld.fr@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2191 bytes --]

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/
>


[-- Attachment #2: .gitignore --]
[-- Type: text/plain, Size: 750 bytes --]

# .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