On 5/9/20 4:55 PM, J.W. Jagersma wrote:

Hi Andris,
Thanks for making gcc 10 available so quickly.  I updated my build
scripts and applied my patch, but then ran into a problem:

     i386-pc-msdosdjgpp-gcc -pipe ... -c symify.c
     i386-pc-msdosdjgpp-ld -s  ../../../lib/crt0.o symify.o ../../../lib/libdbg.a ../../../lib/libc.a -o ../../../bin/symify.exe D:/msys64/usr/local/cross/lib/gcc/i386-pc-msdosdjgpp/10.1.0/libgcc.a -T ../../../lib/djgpp.djl
     D:\msys64\usr\local\cross\bin\i386-pc-msdosdjgpp-ld.exe: ../../../lib/libc.a(stdiohk.o):stdiohk.c:(.data+0x0): multiple definition of `__stdio_cleanup_hook'; ../../../lib/libc.a(exit.o):exit.c:(.bss+0x8): first defined here
     make[2]: *** [makefile:22: ../../../bin/symify.exe] Error 1
     make[1]: *** [makefile.sub:2: all_subs] Error 2
     make: *** [makefile:10: all] Error 2

At first I thought it was caused by my patch, since it looks like this
symbol is placed in .bss in one compilation unit, and .data in another.
However this problem didn't occur with gcc 9.  Inspecting the release
notes for gcc 10, I found that gcc now links with -fno-common by
default, so I think this needs to be fixed in libc now by declaring the
symbol in exit.c with extern linkage:

     extern void (*__stdio_cleanup_hook)(void);

Or alternatively, libc needs to be compiled with -fcommon now.
Did you run into this issue too?  How did you solve it?

Known problem:

int foo;

int foo = 1;

No more works with gcc-10. One must write instead:

extern int foo;

int foo = 1;

Example how it can be fixed can be seen in ArchLinux AUR package which I updated yesterday:

https://aur.archlinux.org/packages/djgpp-djcrx/

Problem is mentioned in https://gcc.gnu.org/gcc-10/changes.html

The changes done for AUR package should perhaps be not committed to DJGPP CVS (no need to support old compilers for ArchLinux)

Andris

PS. Sending also to djgpp mailing list as somebody else could be interested in that