fix symbol clash between conio and ncurses

[stsp]

@ThomasDickey suggests to
rename conio symbols, and then
rename back in conio.h.
That should work.
Although I suppose they also
clash in djgpp! Same conio.
@jwt27 do you know how that
was solved on djgpp side? Do
they tweak the linker to use
--allow-multiple-definition
flag?

[jwt27]

I feel like I'm missing some context here, but I'll guess what's going on.

The linker searches static libraries, in command line order, for unresolved symbols only. When it finds one, it uses the whole object file that defines it. If that object file also defines other symbols, that could cause "multiple definition" errors.

Generally libc is structured so that all symbols can be overridden by other libraries or user code (one function/symbol per file). With conio.c there's a bit more going on. Though, if ncurses defines all the same functions too, and it is linked first, there should be no clash, unless some function is needed that only exists in the libc version.

But you say "same" conio, so I check the file history, and I find: f5d6cf9
Here you directly call gppconio_init() from crt1, so, this is where all of libc's conio.c gets pulled in :)

[stsp]

Thanks, ingenious insight!
I returned djgpp-alike ctors
and reverted the above commit.
What would I do without you. :)

Btw, I wish you'd try dj64 yourself.
You can use its dj32 target if you
want dosbox compatibility. It has
demos within, and also here:
https://github.com/stsp/gopherus
you can take a look at my gopherus
fork which I build with dj64dev.
I even added dosbox-staging.sh
script so that anyone can test the
build immediately. The only limitation
is that networking won't work under
dosbox. Network stack so far only
works with dosemu.