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

  • Allegro library would need to be recompiled with -fgnu89-inline ?

    From [via djgpp@delorie.com]" @21:1/5 to djgpp on Mon Jun 21 18:37:03 2021
    ---- Le lun., 21 juin 2021 18:16:50 -0400 Greg Kennedy (kennedy.greg@gmail.com) [via djgpp@delorie.com] <djgpp@delorie.com> écrit ----



    this is a known issue and I submitted a patch to Allegro github last November >https://github.com/liballeg/allegro5/commit/1d1cc0542c711afe15d4563bbd67f57554ed8d0f

    you might want to review the 4.2 branch on Github as there are a
    couple other fixes for compilation issues in there


    Ok

    I had installed Allegro from:

    http://www.delorie.com/pub/djgpp/current/v2tk/allegro/all422br2.zip http://www.delorie.com/pub/djgpp/current/v2tk/allegro/all422ar2.zip

    that seems they date from: 2007-09-08, which I guess is before the problem was known.





    Uploading new files on DJGPP would avoid the problem for the followers... if any.



    But I may try to compile it myself.
    <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html><head><meta content="text/html;charset=UTF-8" http-equiv="Content-Type"></head><body ><div style="font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 10pt;"><div style=""
    data-zbluepencil-ignore="true" class="zmail_extra"><div id="Zm-_Id_-Sgn1">---- Le lun., 21 juin 2021 18:16:50 -0400 <b>Greg Kennedy (kennedy.greg@gmail.com) [via djgpp@delorie.com] &lt;djgpp@delorie.com&gt;</b> écrit ----<br></div><div><br></div><
    blockquote style="margin: 0px;"><div>&gt;this is a known issue and I submitted a patch to Allegro github last November <br>&gt;<a href="https://github.com/liballeg/allegro5/commit/1d1cc0542c711afe15d4563bbd67f57554ed8d0f" target="_blank">https://github.
    com/liballeg/allegro5/commit/1d1cc0542c711afe15d4563bbd67f57554ed8d0f</a> <br> &gt;<br>&gt;you might want to review the 42 branch on Github as there are a <br>&gt;couple other fixes for compilation issues in there </div><div><br></div><div>Ok<br></div><
    I had installed Allegro from:<br></div><div><a target="_blank" href="http://www.delorie.com/pub/djgpp/current/v2tk/allegro/all422br2.zip">http://www.delorie.com/pub/djgpp/current/v2tk/allegro/all422br2.zip</a></div><div><a target="_blank" href="http:/
    /www.delorie.com/pub/djgpp/current/v2tk/allegro/all422ar2.zip">http://www.delorie.com/pub/djgpp/current/v2tk/allegro/all422ar2.zip</a><br></div><div>that seems they date from: 2007-09-08, which I guess is before the problem was known.<br></div></
    blockquote></div><div><br></div><div>Uploading new files on DJGPP would avoid the problem for the followers.. if any.<br></div><div><br></div><div>But I may try to compile it myself.<br></div><div><br></div></div><br></body></html>

    --- 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 Jun 21 17:16:50 2021
    this is a known issue and I submitted a patch to Allegro github last November https://github.com/liballeg/allegro5/commit/1d1cc0542c711afe15d4563bbd67f57554ed8d0f

    you might want to review the 4.2 branch on Github as there are a
    couple other fixes for compilation issues in there

    On Mon, Jun 21, 2021 at 5:08 PM Paul Dufresne (dufresnep@zoho.com)
    [via djgpp@delorie.com] <djgpp@delorie.com> wrote:

    While compiler kraptor game for DJGPP, I seems to get the same problem as: https://www.allegro.cc/forums/thread/617748

    I tried to recompile the game with: -fgnu89-inline but I believe the library itself
    would have to be recompile if using gcc newer than version 2.x.

    Well, I have some doubts because I would have believe people would have discovered it before me.

    Here is an extract of errors I get:

    ld: obj/djgpp/captura.o:captura.c:(.text+0x110): multiple definition of `is_same_bitmap'; obj/djgpp/bomba.o:bomba.c:(.text+0x110): first defined here
    ld: obj/djgpp/captura.o:captura.c:(.text+0x160): multiple definition of `is_linear_bitmap'; obj/djgpp/bomba.o:bomba.c:(.text+0x160): first defined here
    ld: obj/djgpp/captura.o:captura.c:(.text+0x180): multiple definition of `is_planar_bitmap'; obj/djgpp/bomba.o:bomba.c:(.text+0x180): first defined here
    ld: obj/djgpp/captura.o:captura.c:(.text+0x1a0): multiple definition of `is_memory_bitmap'; obj/djgpp/bomba.o:bomba.c:(.text+0x1a0): first defined here
    ld: obj/djgpp/captura.o:captura.c:(.text+0x1c0): multiple definition of `is_screen_bitmap'; obj/djgpp/bomba.o:bomba.c:(.text+0x1c0): first defined here
    ld: obj/djgpp/captura.o:captura.c:(.text+0x210): multiple definition of `is_video_bitmap'; obj/djgpp/bomba.o:bomba.c:(.text+0x210): first defined here
    ld: obj/djgpp/captura.o:captura.c:(.text+0x220): multiple definition of `is_system_bitmap'; obj/djgpp/bomba.o:bomba.c:(.text+0x220): first defined here
    ld: obj/djgpp/captura.o:captura.c:(.text+0x240): multiple definition of `is_sub_bitmap'; obj/djgpp/bomba.o:bomba.c:(.text+0x240): first defined here
    ld: obj/djgpp/captura.o:captura.c:(.text+0x260): multiple definition of `acquire_bitmap'; obj/djgpp/bomba.o:bomba.c:(.text+0x260): first defined here
    ld: obj/djgpp/captura.o:captura.c:(.text+0x280): multiple definition of `release_bitmap'; obj/djgpp/bomba.o:bomba.c:(.text+0x280): first defined here
    ld: obj/djgpp/captura.o:captura.c:(.text+0x2a0): multiple definition of `acquire_screen'; obj/djgpp/bomba.o:bomba.c:(.text+0x2a0): first defined here
    ld: obj/djgpp/captura.o:captura.c:(.text+0x2d0): multiple definition of `release_screen'; obj/djgpp/bomba.o:bomba.c:(.text+0x2d0): first defined here
    ld: obj/djgpp/captura.o:captura.c:(.text+0x300): multiple definition of `is_inside_bitmap'; obj/djgpp/bomba.o:bomba.c:(.text+0x300): first defined here
    ld: obj/djgpp/captura.o:captura.c:(.text+0x370): multiple definition of `get_clip_rect'; obj/djgpp/bomba.o:bomba.c:(.text+0x370): first defined here
    ld: obj/djgpp/captura.o:captura.c:(.text+0x3a0): multiple definition of `set_clip_state'; obj/djgpp/bomba.o:bomba.c:(.text+0x3a0): first defined here
    ld: obj/djgpp/captura.o:captura.c:(.text+0x3b0): multiple definition of `get_clip_state'; obj/djgpp/bomba.o:bomba.c:(.text+0x3b0): first defined here
    ld: obj/djgpp/captura.o:captura.c:(.text+0x3c0): multiple definition of `makecol15'; obj/djgpp/bomba.o:bomba.c:(.text+0x3c0): first defined here
    ld: obj/djgpp/captura.o:captura.c:(.text+0x400): multiple definition of `makecol16'; obj/djgpp/bomba.o:bomba.c:(.text+0x400): first defined here
    ...
    ld: obj/djgpp/combo.o:combo.c:(.text+0x56c): multiple definition of `getg15'; obj/djgpp/bomba.o:bomba.c:(.text+0x560): first defined here
    ld: obj/djgpp/combo.o:combo.c:(.text+0x589): multiple definition of `getb15'; obj/djgpp/bomba.o:bomba.c:(.text+0x580): first defined here
    ld: obj/djgpp/combo.o:combo.c:(.text+0x5a6): multiple definition of `getr16'; obj/djgpp/bomba.o:bomba.c:(.text+0x5a0): first defined here
    ld: obj/djgpp/combo.o:combo.c:(.text+0x5c3): multiple definition of `getg16'; obj/djgpp/bomba.o:bomba.c:(.text+0x5c0): first defined here
    ld: obj/djgpp/combo.o:combo.c:(.text+0x5e0): multiple definition of `getb16'; obj/djgpp/bomba.o:bomba.c:(.text+0x5e0): first defined here
    ld: obj/djgpp/combo.o:combo.c:(.text+0x5fd): multiple definition of `getr24'; obj/djgpp/bomba.o:bomba.c:(.text+0x600): first defined here
    ld: obj/djgpp/combo.o:combo.c:(.text+0x615): multiple definition of `getg24'; obj/djgpp/bomba.o:bomba.c:(.text+0x620): first defined here
    ld: obj/djgpp/combo.o:combo.c:(.text+0x62d): multiple definition of `getb24'; obj/djgpp/bomba.o:bomba.c:(.text+0x640): first defined here
    ld: obj/djgpp/combo.o:combo.c:(.text+0x645): multiple definition of `getr32'; obj/djgpp/bomba.o:bomba.c:(.text+0x660): first defined here
    ld: obj/djgpp/combo.o:combo.c:(.text+0x65d): multiple definition of `getg32'; obj/djgpp/bomba.o:bomba.c:(.text+0x680): first defined here
    ld: obj/djgpp/combo.o:combo.c:(.text+0x675): multiple definition of `getb32'; obj/djgpp/bomba.o:bomba.c:(.text+0x6a0): first defined here
    ld: obj/djgpp/combo.o:combo.c:(.text+0x68d): multiple definition of `geta32'; obj/djgpp/bomba.o:bomba.c:(.text+0x6c0): first defined here
    ld: obj/djgpp/combo.o:combo.c:(.text+0x6a5): multiple definition of `getpixel'; obj/djgpp/bomba.o:bomba.c:(.text+0x6e0): first defined here
    ld: obj/djgpp/combo.o:combo.c:(.text+0x6c9): multiple definition of `putpixel'; obj/djgpp/bomba.o:bomba.c:(.text+0x6f0): first defined here
    ld: obj/djgpp/combo.o:combo.c:(.text+0x6ee): multiple definition of `_allegro_vline'; obj/djgpp/bomba.o:bomba.c:(.text+0x700): first defined here
    ld: obj/djgpp/combo.o:combo.c:(.text+0x719): multiple definition of `_allegro_hline'; obj/djgpp/bomba.o:bomba.c:(.text+0x710): first defined here
    ld: obj/djgpp/combo.o:combo.c:(.text+0x744): multiple definition of `line'; obj/djgpp/bomba.o:bomba.c:(.text+0x720): first defined here
    ld: obj/djgpp/combo.o:combo.c:(.text+0x772): multiple definition of `fastline'; obj/djgpp/bomba.o:bomba.c:(.text+0x730): first defined here
    ld: obj/djgpp/combo.o:combo.c:(.text+0x7a0): multiple definition of `rectfill'; obj/djgpp/bomba.o:bomba.c:(.text+0x740): first defined here
    ld: obj/djgpp/combo.o:combo.c:(.text+0x7ce): multiple definition of `triangle'; obj/djgpp/bomba.o:bomba.c:(.text+0x750): first defined here
    ld: obj/djgpp/combo.o:combo.c:(.text+0x7ff): multiple definition of `polygon'; obj/djgpp/bomba.o:bomba.c:(.text+0x760): first defined here
    ld: obj/djgpp/combo.o:combo.c:(.text+0x827): multiple definition of `rect'; obj/djgpp/bomba.o:bomba.c:(.text+0x780): first defined here
    ld: obj/djgpp/combo.o:combo.c:(.text+0x858): multiple definition of `circle'; obj/djgpp/bomba.o:bomba.c:(.text+0x7a0): first defined here
    ld: obj/djgpp/combo.o:combo.c:(.text+0x886): multiple definition of `circlefill'; obj/djgpp/bomba.o:bomba.c:(.text+0x7c0): first defined here
    ld: obj/djgpp/combo.o:combo.c:(.text+0x8b4): multiple definition of `ellipse'; obj/djgpp/bomba.o:bomba.c:(.text+0x7e0): first defined here
    ld: obj/djgpp/combo.o:combo.c:(.text+0x8e5): multiple definition of `ellipsefill'; obj/djgpp/bomba.o:bomba.c:(.text+0x800): first defined here
    ld: obj/djgpp/combo.o:combo.c:(.text+0x916): multiple definition of `arc'; obj/djgpp/bomba.o:bomba.c:(.text+0x820): first defined here
    ld: obj/djgpp/combo.o:combo.c:(.text+0x94a): multiple definition of `spline'; obj/djgpp/bomba.o:bomba.c:(.text+0x840): first defined here
    ...
    ld: obj/djgpp/partic.o:partic.c:(.text+0x719): multiple definition of `_allegro_hline'; obj/djgpp/bomba.o:bomba.c:(.text+0x710): first defined here
    ld: obj/djgpp/partic.o:partic.c:(.text+0x744): multiple definition of `line'; obj/djgpp/bomba.o:bomba.c:(.text+0x720): first defined here
    ld: obj/djgpp/partic.o:partic.c:(.text+0x772): multiple definition of `fastline'; obj/djgpp/bomba.o:bomba.c:(.text+0x730): first defined here
    ld: obj/djgpp/partic.o:partic.c:(.text+0x7a0): multiple definition of `rectfill'; obj/djgpp/bomba.o:bomba.c:(.text+0x740): first defined here
    ld: obj/djgpp/partic.o:partic.c:(.text+0x7ce): multiple definition of `triangle'; obj/djgpp/bomba.o:bomba.c:(.text+0x750): first defined here
    ld: obj/djgpp/partic.o:partic.c:(.text+0x7ff): multiple definition of `polygon'; obj/djgpp/bomba.o:bomba.c:(.text+0x760): first defined here
    ld: obj/djgpp/partic.o:partic.c:(.text+0x827): multiple definition of `rect'; obj/djgpp/bomba.o:bomba.c:(.text+0x780): first defined here
    ld: obj/djgpp/partic.o:partic.c:(.text+0x858): multiple definition of `circle'; obj/djgpp/bomba.o:bomba.c:(.text+0x7a0): first defined here
    ld: obj/djgpp/partic.o:partic.c:(.text+0x886): multiple definition of `circlefill'; obj/djgpp/bomba.o:bomba.c:(.text+0x7c0): first defined here
    ld: obj/djgpp/partic.o:partic.c:(.text+0x8b4): multiple definition of `ellipse'; obj/djgpp/bomba.o:bomba.c:(.text+0x7e0): first defined here
    ld: obj/djgpp/partic.o:partic.c:(.text+0x8e5): multiple definition of `ellipsefill'; obj/djgpp/bomba.o:bomba.c:(.text+0x800): first defined here
    ld: obj/djgpp/partic.o:partic.c:(.text+0x916): multiple definition of `arc'; obj/djgpp/bomba.o:bomba.c:(.text+0x820): first defined here
    ld: obj/djgpp/partic.o:partic.c:(.text+0x94a): multiple definition of `spline'; obj/djgpp/bomba.o:bomba.c:(.text+0x840): first defined here
    ld: obj/djgpp/partic.o:partic.c:(.text+0x972): multiple definition of `floodfill'; obj/djgpp/bomba.o:bomba.c:(.text+0x860): first defined here
    ld: obj/djgpp/partic.o:partic.c:(.text+0x99a): multiple definition of `polygon3d'; obj/djgpp/bomba.o:bomba.c:(.text+0x880): first defined here
    ld: obj/djgpp/partic.o:partic.c:(.text+0x9c8): multiple definition of `polygon3d_f'; obj/djgpp/bomba.o:bomba.c:(.text+0x8a0): first defined here
    ld: obj/djgpp/partic.o:partic.c:(.text+0x9f6): multiple definition of `triangle3d'; obj/djgpp/bomba.o:bomba.c:(.text+0x8c0): first defined here
    ld: obj/djgpp/partic.o:partic.c:(.text+0xa27): multiple definition of `triangle3d_f'; obj/djgpp/bomba.o:bomba.c:(.text+0x8e0): first defined here
    ld: obj/djgpp/partic.o:partic.c:(.text+0xa58): multiple definition of `quad3d'; obj/djgpp/bomba.o:bomba.c:(.text+0x900): first defined here
    ld: obj/djgpp/partic.o:partic.c:(.text+0xa8c): multiple definition of `quad3d_f'; obj/djgpp/bomba.o:bomba.c:(.text+0x920): first defined here
    ld: obj/djgpp/partic.o:partic.c:(.text+0xac0): multiple definition of `draw_sprite'; obj/djgpp/bomba.o:bomba.c:(.text+0x940): first defined here
    ld: obj/djgpp/partic.o:partic.c:(.text+0xb0e): multiple definition of `draw_sprite_v_flip'; obj/djgpp/bomba.o:bomba.c:(.text+0x990): first defined here
    ld: obj/djgpp/partic.o:partic.c:(.text+0xb33): multiple definition of `draw_sprite_h_flip'; obj/djgpp/bomba.o:bomba.c:(.text+0x9a0): first defined here
    ld: obj/djgpp/partic.o:partic.c:(.text+0xb58): multiple definition of `draw_sprite_vh_flip'; obj/djgpp/bomba.o:bomba.c:(.text+0x9b0): first defined here
    ld: obj/djgpp/partic.o:partic.c:(.text+0xb7d): multiple definition of `draw_trans_sprite'; obj/djgpp/bomba.o:bomba.c:(.text+0x9c0): first defined here
    ld: obj/djgpp/partic.o:partic.c:(.text+0xbcb): multiple definition of `draw_lit_sprite'; obj/djgpp/bomba.o:bomba.c:(.text+0xa10): first defined here
    ld: obj/djgpp/partic.o:partic.c:(.text+0xbf6): multiple definition of `draw_gouraud_sprite'; obj/djgpp/bomba.o:bomba.c:(.text+0xa20): first defined here
    ld: obj/djgpp/partic.o:partic.c:(.text+0xc2a): multiple definition of `draw_character_ex'; obj/djgpp/bomba.o:bomba.c:(.text+0xa40): first defined here
    ld: obj/djgpp/partic.o:partic.c:(.text+0xc58): multiple definition of `rotate_sprite'; obj/djgpp/bomba.o:bomba.c:(.text+0xa50): first defined here
    ld: obj/djgpp/partic.o:partic.c:(.text+0xccc): multiple definition of `rotate_sprite_v_flip'; obj/djgpp/bomba.o:bomba.c:(.text+0xaa0): first defined here
    ld: obj/djgpp/partic.o:partic.c:(.text+0xd40): multiple definition of `rotate_scaled_sprite'; obj/djgpp/bomba.o:bomba.c:(.text+0xaf0): first defined here
    ld: obj/djgpp/partic.o:partic.c:(.text+0xdcc): multiple definition of `rotate_scaled_sprite_v_flip'; obj/djgpp/bomba.o:bomba.c:(.text+0xb60): first defined here
    ld: obj/djgpp/partic.o:partic.c:(.text+0xe58): multiple definition of `pivot_sprite'; obj/djgpp/bomba.o:bomba.c:(.text+0xbd0): first defined here
    ld: obj/djgpp/partic.o:partic.c:(.text+0xeab): multiple definition of `pivot_sprite_v_flip'; obj/djgpp/bomba.o:bomba.c:(.text+0xc20): first defined her


    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to djgpp on Sat Jun 26 14:15:56 2021
    Copy: freedos-devel@lists.sourceforge.net (freedos-devel)

    Ok I did encounter again a multiple definition error with ld (linking) in a different project today.



    The idea seems that if you have multiple files that include some.h, and in it you have functions or

    variables not using the static keyword (at least for C), then they will be defined as global, and so,

    they will be define each time some.h is included. Making multiple declarations at linking time errors.



    Somehow, it seems it is more a problem with gcc 10 (or the linker associated with it) than in previous

    versions... not clear how much recent it is.



    Did not check how much it apply to Allegro.
    <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html><head><meta content="text/html;charset=UTF-8" http-equiv="Content-Type"></head><body ><div style="font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 10pt;"><div>Ok I did
    encounter again a multiple definition error with ld (linking) in a different project today.<br></div><div><br></div><div>The idea seems that if you have multiple files that include some.h, and in it you have functions or<br></div><div>variables not using
    the static keyword (at least for C), then they will be defined as global, and so,<br></div><div>they will be define each time some.h is included. Making multiple declarations at linking time errors.<br></div><div><br></div><div>Somehow, it seems it is
    more a problem with gcc 10 (or the linker associated with it) than in previous<br></div><div>versions... not clear how much recent it is.<br></div><div><br></div><div>Did not check how much it apply to Allegro<br></div><div><br></div><div><br></div></div>
    <br></body></html>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to djgpp on Sat Jun 26 18:20:36 2021
    Copy: freedos-devel@lists.sourceforge.net (freedos-devel)

    I now think that adding "external" before declarations in .h is the correct solution.

    If they were not mark static already, it is that the value is expected to be shared (being global).

    The solution is *I now think* to add external, and have the real declaration in a unique place, like in main.c.
    <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html><head><meta content="text/html;charset=UTF-8" http-equiv="Content-Type"></head><body ><div style="font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 10pt;"><div>I now think
    that adding "external" before declarations in .h is the correct solution.<br></div><div>If they were not mark static already, it is that the value is expected to be shared (being global).<br></div><div>The solution is *I now think* to add external, and
    have the real declaration in a unique place, like in main.c.<br></div></div><br></body></html>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Damien Guibouret@21:1/5 to djgpp@delorie.com] on Sun Jun 27 18:07:59 2021
    Hello,

    This is a change in behaviour of GCC-10: last change described in https://gcc.gnu.org/gcc-10/changes.html#c

    Using -fcommon is certainly not the correct correction (but could be a workaround for old programs with a lot of occurence of this problem),
    but adding extern or static depending on if the variable should be
    shared or not is better.

    Regards,

    Damien

    On 27/06/2021 00:20, Paul Dufresne (dufresnep@zoho.com) [via
    djgpp@delorie.com] wrote:
    I now think that adding "external" before declarations in .h is the
    correct solution.
    If they were not mark static already, it is that the value is expected
    to be shared (being global).
    The solution is *I now think* to add external, and have the real
    declaration in a unique place, like in main.c.


    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Hans-Bernhard_Br=c3=b6ker@21:1/5 to All on Sun Jun 27 22:52:57 2021
    Am 27.06.2021 um 18:07 schrieb Damien Guibouret:

    Using -fcommon is certainly not the correct correction (but could be a workaround for old programs with a lot of occurence of this problem),
    but adding extern or static depending on if the variable should be
    shared or not is better.

    Adding 'static' into a header is hardly ever the right solution.

    The rules of thumb are: never write 'extern' in a *.c file, and never
    'static' in a *.h file.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to djgpp on Sun Jun 27 17:50:12 2021
    Copy: freedos-devel@lists.sourceforge.net (freedos-devel)

    ---- Le sam., 26 juin 2021 18:20:36 -0400 Paul Dufresne <mailto:dufresnep@zoho.com> I wrote ----

    I now think that adding "external" before declarations in .h is the correct solution.

    If they were not mark static already, it is that the value is expected to be shared (being global).

    The solution is *I now think* to add external, and have the real declaration in a unique place, like in main.c.







    I can now confirm this is a change in GCC 10 ( from https://gcc.gnu.org/gcc-10/changes.html ):

    "GCC now defaults to -fno-common. As a result, global
    variable accesses are more efficient on various targets. In C, global
    variables with multiple tentative definitions now result in linker errors.
    With -fcommon such definitions are silently merged during
    linking."



    More details in:

    https://gcc.gnu.org/gcc-10/porting_to.html#common



    I am now realizing it can be tedious to rearrage the code to initialize stuff only once.

    -fcommon could allows us to do the bad thing for some time
    <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html><head><meta content="text/html;charset=UTF-8" http-equiv="Content-Type"></head><body ><div style="font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 10pt;"><div style=""
    data-zbluepencil-ignore="true" class="zmail_extra"><div id="Zm-_Id_-Sgn1">---- Le sam., 26 juin 2021 18:20:36 -0400 <b>Paul Dufresne &lt;<a target="_blank" href="mailto:dufresnep@zoho.com">dufresnep@zoho.com</a>&gt;</b> I wrote ----<br></div><div>&gt;I
    now think that adding "external" before declarations in .h is the correct solution.<br></div><blockquote style="margin: 0px;"><div><div style="font-family : Verdana, Arial, Helvetica, sans-serif; font-size : 10pt; "><div>&gt;If they were not mark
    static already, it is that the value is expected to be shared (being global).<br></div><div>&gt;The solution is *I now think* to add external, and have the real declaration in a unique place, like in main.c.<br></div></div></div></blockquote></div><div><
    </div><div>I can now confirm this is a change in GCC 10 ( from <a target="_blank" href="https://gcc.gnu.org/gcc-10/changes.html">https://gcc.gnu.org/gcc-10/changes.html</a> ):<br></div><div>"GCC now defaults to <code>-fno-common</code>. As a result,
    global
    variable accesses are more efficient on various targets. In C, global
    variables with multiple tentative definitions now result in linker errors.
    With <code>-fcommon</code> such definitions are silently merged during
    linking."<br></div><div><br></div><div>More details in:<br></div><div><a target="_blank" href="https://gcc.gnu.org/gcc-10/porting_to.html#common">https://gcc.gnu.org/gcc-10/porting_to.html#common</a><br></div><div><br></div><div>I am now realizing
    it can be tedious to rearrage the code to initialize stuff only once.<br></div><div>-fcommon could allows us to do the bad thing for some time<br></div></div><br></body></html>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to freedos-devel on Wed Jun 30 11:14:17 2021
    Copy: djgpp@delorie.com (djgpp)

    While reading by mistake https://gcc.gnu.org/onlinedocs/cpp/Invocation.html

    (I had searched for gcc invocation)

    So this is the preprocessor (to gcc).



    I noted these parameters that can seems usefull for FreeDOS and less for DJGPP:



    -remap

    Enable special code to work around file systems which only permit very
    short file names, such as MS-DOS.


    -fexec-charset=charset

    Set the execution character set, used for string and character
    constants. The default is UTF-8. charset can be any encoding
    supported by the system’s iconv library routine.


    -finput-charset=charset

    Set the input character set, used for translation from the character
    set of the input file to the source character set used by GCC. If the
    locale does not specify, or GCC cannot get this information from the
    locale, the default is UTF-8. This can be overridden by either the locale
    or this command-line option. Currently the command-line option takes precedence if there’s a conflict. charset can be any encoding
    supported by the system’s iconv library routine.
    <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html><head><meta content="text/html;charset=UTF-8" http-equiv="Content-Type"></head><body ><div style="font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 10pt;"><div>While
    reading by mistake <a target="_blank" href="https://gcc.gnu.org/onlinedocs/cpp/Invocation.html">https://gcc.gnu.org/onlinedocs/cpp/Invocation.html</a><br></div><div>(I had searched for gcc invocation)<br></div><div>So this is the preprocessor (to gcc).<
    </div><div><br></div><div>I noted these parameters that can seems usefull for FreeDOS and less for DJGPP:<br></div><div><br></div><dt><code>-remap</code><br></dt><dd><p>Enable special code to work around file systems which only permit very
    short file names, such as MS-DOS.<br></p></dd><dt><code>-fexec-charset=<var>charset</var></code><br></dt><dd><p>Set the execution character set, used for string and character
    constants. The default is UTF-8. <var>charset</var> can be any encoding supported by the system’s <code>iconv</code> library routine.<br></p></dd><dt><code>-finput-charset=<var>charset</var></code><br></dt><dd><p>Set the input character set, used for translation from the character
    set of the input file to the source character set used by GCC. If the
    locale does not specify, or GCC cannot get this information from the
    locale, the default is UTF-8. This can be overridden by either the locale
    or this command-line option. Currently the command-line option takes precedence if there’s a conflict. <var>charset</var> can be any encoding supported by the system’s <code>iconv</code> library routine.<br></p></dd><div><br></div></div><br></body></html>

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