1. Forum
  2. Usenet
  3. COMP.OS.MSDOS.DJGPP

  • Re: DJGPP build of gcc-10.3.0 and make 4.3 incompatibility

    From Stefan Ring@21:1/5 to Stefan Ring on Mon Nov 1 02:48:23 2021
    On Monday, November 1, 2021 at 10:21:03 AM UTC+1, Stefan Ring wrote:
    While trying to recreate the DJGPP gcc binaries, by following the excellent instructions in readme.DJGPP, I stumbled across this problem that caused me a lot of grief. I used Windows XP for building and even installed Vista as a possible remedy, but to
    no avail. The same thing happened there.

    The last line in libgcc/Makefile.in does an include of *.dep, but somehow in make 4.3 the expansion of this wildcard expression gets truncated somewhere in the middle, and then it complains about not being able to find the file whose name got truncated.
    I patched around this by splitting it up into multiple chunks of wildcard matches on multiple lines, but this got me further only by a tiny amount. The next problem was that during an "exit 0" in the configuration stage, make would say "memory fouled"
    and abort.

    After switching to make 4.1r2, the build worked beautifully.

    I forgot to mention: I used Andris Pavenis' builds from the directory "rpms/djcross-gcc-10.3.0" to create gcc1030s.zip and this in turn for building on Windows. And I consider it very likely that at least 10.2.0 will be affected in the same way, but I
    have not tested this.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Stefan Ring@21:1/5 to All on Mon Nov 1 02:21:02 2021
    While trying to recreate the DJGPP gcc binaries, by following the excellent instructions in readme.DJGPP, I stumbled across this problem that caused me a lot of grief. I used Windows XP for building and even installed Vista as a possible remedy, but to
    no avail. The same thing happened there.

    The last line in libgcc/Makefile.in does an include of *.dep, but somehow in make 4.3 the expansion of this wildcard expression gets truncated somewhere in the middle, and then it complains about not being able to find the file whose name got truncated.
    I patched around this by splitting it up into multiple chunks of wildcard matches on multiple lines, but this got me further only by a tiny amount. The next problem was that during an "exit 0" in the configuration stage, make would say "memory fouled"
    and abort.

    After switching to make 4.1r2, the build worked beautifully.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Stefan Ring@21:1/5 to djgpp@delorie.com] on Wed Nov 3 07:51:00 2021
    On Wednesday, November 3, 2021 at 3:43:44 PM UTC+1, Andris Pavenis (andris.pavenis@iki.fi) [via djgpp@delorie.com] wrote:
    Actually gcc-10.3.0 was built for DJGPP, just not uploaded (both RPMs and DJGPP packages).
    Uploading could be easy.

    Problem with cross-compiler:

    - libstdc++v3 configure does not check correctly available C library functions and as result they
    may not be put into std namespace. I would like to do cross-native build (building DJGPP native
    compiler using cross-compiler from Linux but it would have the same problem with libstdc++

    Also:

    Actually myös SRPM package is generated. Generating script is not in SRPM or gccXXXs.zip but can be
    found in my GCC repo fork in GitHub.

    For djgpp/native/gcc-10 branch it is:

    https://github.com/apavenis/djgpp-gcc/blob/djgpp/native/gcc-10/djgpp/mk-djcross-gcc.sh

    Script generates

    - SRPM package

    - patch to be applied for ArchLinux build

    Yeah, I figured out most of this, and I already used the SRPM to build the zip and build that on Windows. I just noticed that it does not work with (djgpp) make 4.3, but it does with make 4.1r2 (from the directory "deleted", IIRC).

    I also did a cross-native build of gcc-10.3, and it seemed to work ok, but I did not test it on anything more sophisticated than a C++ "Hello World".

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to djgpp@delorie.com] on Wed Nov 3 16:43:23 2021
    On 11/1/21 11:48, Stefan Ring (stefanrin@gmail.com) [via djgpp@delorie.com] wrote:
    On Monday, November 1, 2021 at 10:21:03 AM UTC+1, Stefan Ring wrote:
    While trying to recreate the DJGPP gcc binaries, by following the excellent instructions in readme.DJGPP, I stumbled across this problem that caused me a lot of grief. I used Windows XP for building and even installed Vista as a possible remedy, but
    to no avail. The same thing happened there.

    The last line in libgcc/Makefile.in does an include of *.dep, but somehow in make 4.3 the expansion of this wildcard expression gets truncated somewhere in the middle, and then it complains about not being able to find the file whose name got
    truncated. I patched around this by splitting it up into multiple chunks of wildcard matches on multiple lines, but this got me further only by a tiny amount. The next problem was that during an "exit 0" in the configuration stage, make would say "memory
    fouled" and abort.

    After switching to make 4.1r2, the build worked beautifully.
    I forgot to mention: I used Andris Pavenis' builds from the directory "rpms/djcross-gcc-10.3.0" to create gcc1030s.zip and this in turn for building on Windows. And I consider it very likely that at least 10.2.0 will be affected in the same way, but I
    have not tested this.

    Actually gcc-10.3.0 was built for DJGPP, just not uploaded (both RPMs and DJGPP packages).
    Uploading could be easy.

    gcc-11 is a different story:

    - Ada library does not compile - alignment issues which are likely to cause problems also for other
    languages like (c or C++) when SSE or AVX is being used (and maybe even with earlier GCC versions)

    - I have build gcc-11 cross-compiler under ArchLinux (leaving Ada out). There was some problems
    building RPM but I have not studied them in more details

    - Also building native compiler failed (also without Ada)


    Problem with cross-compiler:

    - libstdc++v3 configure does not check correctly available C library functions and as result they
    may not be put into std namespace. I would like to do cross-native build (building DJGPP native
    compiler using cross-compiler from Linux but it would have the same problem with libstdc++

    Also:

    Actually myös SRPM package is generated. Generating script is not in SRPM or gccXXXs.zip but can be
    found in my GCC repo fork in GitHub.

    For djgpp/native/gcc-10 branch it is:

    https://github.com/apavenis/djgpp-gcc/blob/djgpp/native/gcc-10/djgpp/mk-djcross-gcc.sh

    Script generates

    - SRPM package

    - patch to be applied for ArchLinux build


    Andris

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From RayeR@21:1/5 to All on Thu Nov 4 18:29:54 2021
    Another user have problem with Make 4.3 when compiling Mplayer for DOS: http://www.bttr-software.de/forum/forum_entry.php?id=18363

    H:\DJGPP\BUILD\MPLAYER\MPLAYER>make
    Exiting due to signal SIGSEGV
    Page fault at eip=0002b22e, error=0004
    eax=00000001 ebx=00000030 ecx=000fec10 edx=000febe0 esi=000d9578 edi=00000000 ebp=000d9558 esp=000d9550 program=H:\DJGPP\BIN\MAKE.EXE
    cs: sel=00a7 base=00400000 limit=0011ffff
    ds: sel=00af base=00400000 limit=0011ffff
    es: sel=00af base=00400000 limit=0011ffff
    fs: sel=008f base=00018190 limit=0000ffff
    gs: sel=00bf base=00000000 limit=0010ffff
    ss: sel=00af base=00400000 limit=0011ffff
    App stack: [000daa50..0005aa50] Exceptn stack: [0005a96c..00058a2c]

    Neither increasing of transfer buffer in stub didn't help.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to djgpp@delorie.com] on Mon Nov 8 10:53:46 2021
    On 2021-11-03 15:43, Andris Pavenis (andris.pavenis@iki.fi) [via djgpp@delorie.com] wrote:
    Actually gcc-10.3.0 was built for DJGPP, just not uploaded (both RPMs and DJGPP packages). Uploading could be easy.

    I've been waiting for djcross-gcc-10.3.0.tar.bz2, please do upload :)

    gcc-11 is a different story:

    - Ada library does not compile - alignment issues which are likely to cause problems also for other languages like (c or C++) when SSE or AVX is being used (and maybe even with earlier GCC versions)

    What sort of alignment issues? I already ran into alignment trouble with SSE (at run-time, not compile-time). To work around it, in the linker script I put SUBALIGN(0x10) on the .text and .bss sections. For .data this is not possible because it leaves gaps in the ctors/dtors list, so I ended up linking
    *(.data .data.* .gnu.linkonce.d*) in .text. A bit of a hack but .text is writable. I suppose the input section alignment could be changed in binutils somewhere though.

    Also in libc I had to put attribute __attribute__((force_align_arg_pointer)) on __crt1_startup() to align the stack for ctors & main(). Alternatively this alignment could be performed manually in crt0.S.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to djgpp@delorie.com] on Tue Nov 9 18:43:53 2021
    On 11/8/21 11:53, J.W. Jagersma (jwjagersma@gmail.com) [via djgpp@delorie.com] wrote:
    On 2021-11-03 15:43, Andris Pavenis (andris.pavenis@iki.fi) [via djgpp@delorie.com] wrote:
    Actually gcc-10.3.0 was built for DJGPP, just not uploaded (both RPMs and DJGPP packages).
    Uploading could be easy.

    I've been waiting for djcross-gcc-10.3.0.tar.bz2, please do upload :)


    File was already inside SRPM file so it was available. Just download size was big, Extracted and
    uploaded


    gcc-11 is a different story:

    - Ada library does not compile - alignment issues which are likely to cause problems also for
    other languages like (c or C++) when SSE or AVX is being used (and maybe even with earlier GCC
    versions)

    What sort of alignment issues?  I already ran into alignment trouble with SSE
    (at run-time, not compile-time).  To work around it, in the linker script I put
    SUBALIGN(0x10) on the .text and .bss sections.  For .data this is not possible
    because it leaves gaps in the ctors/dtors list, so I ended up linking
    *(.data .data.* .gnu.linkonce.d*) in .text.  A bit of a hack but .text is writable.  I suppose the input section alignment could be changed in binutils
    somewhere though.

    Also in libc I had to put attribute __attribute__((force_align_arg_pointer)) on
    __crt1_startup() to align the stack for ctors & main(). Alternatively this alignment could be performed manually in crt0.S.

    I was thinking about possible runtime alignment problems.I have not tested it myself. Ada library
    has some alignment checks and as far as I understand refuses to compile as max. available alignment
    is not sufficient (error message is not clear).

    Andris

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to djgpp@delorie.com] on Wed Nov 10 12:44:18 2021
    On 2021-11-09 17:43, Andris Pavenis (andris.pavenis@iki.fi) [via djgpp@delorie.com] wrote:
    On 11/8/21 11:53, J.W. Jagersma (jwjagersma@gmail.com) [via djgpp@delorie.com] wrote:
    On 2021-11-03 15:43, Andris Pavenis (andris.pavenis@iki.fi) [via djgpp@delorie.com] wrote:
    Actually gcc-10.3.0 was built for DJGPP, just not uploaded (both RPMs and DJGPP packages). Uploading could be easy.

    I've been waiting for djcross-gcc-10.3.0.tar.bz2, please do upload :)


    File was already inside SRPM file so it was available. Just download size was big, Extracted and uploaded

    Thanks!


    gcc-11 is a different story:

    - Ada library does not compile - alignment issues which are likely to cause problems also for other languages like (c or C++) when SSE or AVX is being used (and maybe even with earlier GCC versions)

    What sort of alignment issues?  I already ran into alignment trouble with SSE
    (at run-time, not compile-time).  To work around it, in the linker script I put
    SUBALIGN(0x10) on the .text and .bss sections.  For .data this is not possible
    because it leaves gaps in the ctors/dtors list, so I ended up linking
    *(.data .data.* .gnu.linkonce.d*) in .text.  A bit of a hack but .text is >> writable.  I suppose the input section alignment could be changed in binutils
    somewhere though.

    Also in libc I had to put attribute __attribute__((force_align_arg_pointer)) on
    __crt1_startup() to align the stack for ctors & main(). Alternatively this >> alignment could be performed manually in crt0.S.

    I was thinking about possible runtime alignment problems.I have not tested it myself. Ada library has some alignment checks and as far as I understand refuses to compile as max. available alignment is not sufficient (error message is not clear).

    I expect it would require 16-byte alignment as with SSE. GCC has also used 16-byte default stack alignment for a while now, amd64 ABI also enforces this. I'm curious to know how the Ada compiler detects it though.

    Currently in binutils only '.text' and '.data' are 16-byte aligned, as well as '.gnu.linkonce.{d,t,r}*', but not named sections such as '.text.unlikely', etc. If you compile with -ffunction-sections -fdata-sections then nothing will be aligned at all.
    Also '.bss*', '.gnu.linkonce.b*', '.const*' and '.rodata*' are only 4-byte aligned since there is no alignment entry defined for them.

    Following patch should fix all this without ldscript hacks. Stack alignment still needs to be done in libc of course, and I also noticed the ALIGN macro for malloc would need to be increased (nmalcdef.h:191).

    (I don't know if the .const entry here is necessary, the linker script uses it but gcc only seems to produce .rodata...)

    diff --git a/bfd/coff-go32.c b/bfd/coff-go32.c
    index d73c32b215d..3139ce07ac7 100644
    --- a/bfd/coff-go32.c
    +++ b/bfd/coff-go32.c
    @@ -28,9 +28,15 @@
    #define COFF_LONG_FILENAMES

    #define COFF_SECTION_ALIGNMENT_ENTRIES \
    -{ COFF_SECTION_NAME_EXACT_MATCH (".data"), \
    +{ COFF_SECTION_NAME_PARTIAL_MATCH (".data"), \
    COFF_ALIGNMENT_FIELD_EMPTY, COFF_ALIGNMENT_FIELD_EMPTY, 4 }, \
    -{ COFF_SECTION_NAME_EXACT_MATCH (".text"), \
    +{ COFF_SECTION_NAME_PARTIAL_MATCH (".text"), \
    + COFF_ALIGNMENT_FIELD_EMPTY, COFF_ALIGNMENT_FIELD_EMPTY, 4 }, \
    +{ COFF_SECTION_NAME_PARTIAL_MATCH (".const"), \
    + COFF_ALIGNMENT_FIELD_EMPTY, COFF_ALIGNMENT_FIELD_EMPTY, 4 }, \
    +{ COFF_SECTION_NAME_PARTIAL_MATCH (".rodata"), \
    + COFF_ALIGNMENT_FIELD_EMPTY, COFF_ALIGNMENT_FIELD_EMPTY, 4 }, \
    +{ COFF_SECTION_NAME_PARTIAL_MATCH (".bss"), \
    COFF_ALIGNMENT_FIELD_EMPTY, COFF_ALIGNMENT_FIELD_EMPTY, 4 }, \
    { COFF_SECTION_NAME_PARTIAL_MATCH (".gnu.linkonce.d"), \
    COFF_ALIGNMENT_FIELD_EMPTY, COFF_ALIGNMENT_FIELD_EMPTY, 4 }, \
    @@ -38,6 +44,8 @@
    COFF_ALIGNMENT_FIELD_EMPTY, COFF_ALIGNMENT_FIELD_EMP
  • From [via djgpp@delorie.com]" @21:1/5 to J.W. Jagersma on Sat Nov 20 14:40:24 2021
    On 2021-11-10 12:44, J.W. Jagersma wrote:
    On 2021-11-09 17:43, Andris Pavenis (andris.pavenis@iki.fi) [via djgpp@delorie.com] wrote:
    I was thinking about possible runtime alignment problems.I have not tested it myself. Ada library has some alignment checks and as far as I understand refuses to compile as max. available alignment is not sufficient (error message is not clear).

    I expect it would require 16-byte alignment as with SSE.  GCC has also used 16-byte default stack alignment for a while now, amd64 ABI also enforces this.
    I'm curious to know how the Ada compiler detects it though.

    Currently in binutils only '.text' and '.data' are 16-byte aligned, as well as
    '.gnu.linkonce.{d,t,r}*', but not named sections such as '.text.unlikely', etc.
    If you compile with -ffunction-sections -fdata-sections then nothing will be aligned at all.
    Also '.bss*', '.gnu.linkonce.b*', '.const*' and '.rodata*' are only 4-byte aligned since there is no alignment entry defined for them.

    Following patch should fix all this without ldscript hacks.  Stack alignment still needs to be done in libc of course, and I also noticed the ALIGN macro for malloc would need to be increased (nmalcdef.h:191).

    (I don't know if the .const entry here is necessary, the linker script uses it
    but gcc only seems to produce .rodata...)

    diff --git a/bfd/coff-go32.c b/bfd/coff-go32.c
    index d73c32b215d..3139ce07ac7 100644
    --- a/bfd/coff-go32.c
    +++ b/bfd/coff-go32.c
    @@ -28,9 +28,15 @@
     #define COFF_LONG_FILENAMES

     #define COFF_SECTION_ALIGNMENT_ENTRIES \
    -{ COFF_SECTION_NAME_EXACT_MATCH (".data"), \
    +{ COFF_SECTION_NAME_PARTIAL_MATCH (".data"), \
       COFF_ALIGNMENT_FIELD_EMPTY, COFF_ALIGNMENT_FIELD_EMPTY, 4 }, \
    -{ COFF_SECTION_NAME_EXACT_MATCH (".text"), \
    +{ COFF_SECTION_NAME_PARTIAL_MATCH (".text"), \
    +  COFF_ALIGNMENT_FIELD_EMPTY, COFF_ALIGNMENT_FIELD_EMPTY, 4 }, \
    +{ COFF_SECTION_NAME_PARTIAL_MATCH (".const"), \
    +  COFF_ALIGNMENT_FIELD_EMPTY, COFF_ALIGNMENT_FIELD_EMPTY, 4 }, \
    +{ COFF_SECTION_NAME_PARTIAL_MATCH (".rodata"), \
    +  COFF_ALIGNMENT_FIELD_EMPTY, COFF_ALIGNMENT_FIELD_EMPTY, 4 }, \
    +{ COFF_SECTION_NAME_PARTIAL_MATCH (".bss"), \
       COFF_ALIGNMENT_FIELD_EMPTY, COFF_ALIGNMENT_FIELD_EMPTY, 4 }, \
     { COFF_SECTION_NAME_PARTIAL_MATCH (".gnu.linkonce.d"), \
       COFF_ALIGNMENT_FIELD_EMPTY, COFF_ALIGNMENT_FIELD_EMPTY, 4 }, \
    @@ -38,6 +44,8 @@
       COFF_ALIGNMENT_FIELD_EMPTY, COFF_ALIGNMENT_FIELD_EMPTY, 4 }, \
     { COFF_SECTION_NAME_PARTIAL_MATCH (".gnu.linkonce.r"), \
       COFF_ALIGNMENT_FIELD_EMPTY, COFF_ALIGNMENT_FIELD_EMPTY, 4 }, \
    +{ COFF_SECTION_NAME_PARTIAL_MATCH (".gnu.linkonce.b"), \
    +  COFF_ALIGNMENT_FIELD_EMPTY, COFF_ALIGNMENT_FIELD_EMPTY, 4 }, \
     { COFF_SECTION_NAME_PARTIAL_MATCH (".debug"), \
       COFF_ALIGNMENT_FIELD_EMPTY, COFF_ALIGNMENT_FIELD_EMPTY, 0 }, \
     { COFF_SECTION_NAME_PARTIAL_MATCH (".gnu.linkonce.wi"), \

    Any objections if I submit this to binutils? Even if it doesn't fix Ada, we still need this for reliable SSE support.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)