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

  • binutils 2.37 fails PDCurses library make with "ar: invalid operation"

    From Jamie Bainbridge@21:1/5 to All on Fri Dec 31 20:03:57 2021
    Hello,

    Compiling the PDCurses-3.9 source with the latest binutils (bnu237b) fails to create the library file with:

    ar: curses.a: invalid operation

    You can also reproduce the same error easily with the same command manually:

    ar rcv curses.a *.o

    ar makes a small 8-byte curses.a file but that's obviously not valid.

    Trying several previous versions (bnu232b, bnu234b, bnu2351b) with the same compiled object files all work fine.

    I'm compiling the latest stable PDCurses from upstream: https://github.com/wmcbrine/PDCurses/releases/tag/3.9

    The only change I've made is to add -DPDC_RGB to CFLAGS and change the LIBCURSES variable to "curses.a".

    My environment is dosbox-staging. I've set "LFN=n" in djgpp.env as DOSBox doesn't have LFN support (at least not this fork of it). There are no long filenames involved here anyway.

    I hope that's a useful enough error report. Please let me know if I can provide any more information.

    Jamie

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to All on Sat Jan 1 14:24:59 2022
    Am Fri, 31 Dec 2021 20:03:57 -0800 (PST)
    schrieb "Jamie Bainbridge (jamie.bainbridge@gmail.com) [via
    djgpp@delorie.com]" <djgpp@delorie.com>:

    Hello,

    Compiling the PDCurses-3.9 source with the latest binutils (bnu237b)
    fails to create the library file with:

    ar: curses.a: invalid operation

    You can also reproduce the same error easily with the same command
    manually:

    ar rcv curses.a *.o

    ar makes a small 8-byte curses.a file but that's obviously not valid.

    Trying several previous versions (bnu232b, bnu234b, bnu2351b) with
    the same compiled object files all work fine.

    I'm compiling the latest stable PDCurses from upstream: https://github.com/wmcbrine/PDCurses/releases/tag/3.9

    The only change I've made is to add -DPDC_RGB to CFLAGS and change
    the LIBCURSES variable to "curses.a".

    My environment is dosbox-staging. I've set "LFN=n" in djgpp.env as
    DOSBox doesn't have LFN support (at least not this fork of it). There
    are no long filenames involved here anyway.

    I hope that's a useful enough error report. Please let me know if I
    can provide any more information.

    Jamie


    Hello,

    Sorry but I cannot reproduce this at all.
    I only use VMware as virtual machine. I have tested it on four
    different environments:
    - DOS box of Windows 98 SE without LFN support
    - MS-DOS 7.1 without LFN support
    - MS-DOS 6.22 without LFN support
    - FreeDOS 1.3 RC5 without LFN support

    My DJGPP installation uses djdev206 (aka cvs repository code), gcc346b
    and bnu237b. I have compiled the DJGPP port of PDCurses-3.9 (aka
    pdcur39s) but I do not think that this shall have any impact in the
    analysis of this issue. None of the builds have failed. It was also
    possible to manually create an archive issuing the command:
    ar rcv curses.a *.o
    All builds have been checked by building the test programs. They all
    have run flawlessly. The builds have been repeated 5 times for every environment, with and without defining PDC_RGB. But I think that neither
    LFN support nor -DPDC_RGB have any impact in this issue.
    I will try to install dosbox and see if I can reproduce the issue there.

    Regards,
    Juan M. Guerrero

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to All on Sun Jan 2 00:01:02 2022
    Am Fri, 31 Dec 2021 20:03:57 -0800 (PST)
    schrieb "Jamie Bainbridge (jamie.bainbridge@gmail.com) [via
    djgpp@delorie.com]" <djgpp@delorie.com>:

    Hello,

    Compiling the PDCurses-3.9 source with the latest binutils (bnu237b)
    fails to create the library file with:

    ar: curses.a: invalid operation

    You can also reproduce the same error easily with the same command
    manually:

    ar rcv curses.a *.o

    ar makes a small 8-byte curses.a file but that's obviously not valid.

    Trying several previous versions (bnu232b, bnu234b, bnu2351b) with
    the same compiled object files all work fine.

    I'm compiling the latest stable PDCurses from upstream: https://github.com/wmcbrine/PDCurses/releases/tag/3.9

    The only change I've made is to add -DPDC_RGB to CFLAGS and change
    the LIBCURSES variable to "curses.a".

    My environment is dosbox-staging. I've set "LFN=n" in djgpp.env as
    DOSBox doesn't have LFN support (at least not this fork of it). There
    are no long filenames involved here anyway.

    I hope that's a useful enough error report. Please let me know if I
    can provide any more information.

    Jamie


    OFYI, after having installed DOSBox I was able to reproduce the bug.
    What the maintariners of binutils have changed between bnu2351b and
    bnu237b is completely unknown to me. It seems to be a DOSBox specific
    issue and AFIAK DOSBox has never been recommended to be used as DJGPP development environment. I will try to investigate this issue when I
    have enough time. This will not be quite soon.

    Use bnu2351b; AFAIK there are no DJGPP specific changes between
    bnu2351b and bnu237b.


    Regrads,
    Juan M. Guerrero

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jamie Bainbridge@21:1/5 to djgpp@delorie.com] on Sat Jan 1 17:30:43 2022
    On Sunday, 2 January 2022 at 9:01:39 am UTC+10, Juan Manuel Guerrero (juan.guerrero@gmx.de) [via djgpp@delorie.com] wrote:
    Am Fri, 31 Dec 2021 20:03:57 -0800 (PST)
    schrieb "Jamie Bainbridge (jamie.ba...@gmail.com) [via
    dj...@delorie.com]" <dj...@delorie.com>:
    Hello,

    Compiling the PDCurses-3.9 source with the latest binutils (bnu237b)
    fails to create the library file with:

    ar: curses.a: invalid operation

    You can also reproduce the same error easily with the same command manually:

    ar rcv curses.a *.o

    ar makes a small 8-byte curses.a file but that's obviously not valid.

    Trying several previous versions (bnu232b, bnu234b, bnu2351b) with
    the same compiled object files all work fine.

    I'm compiling the latest stable PDCurses from upstream: https://github.com/wmcbrine/PDCurses/releases/tag/3.9

    The only change I've made is to add -DPDC_RGB to CFLAGS and change
    the LIBCURSES variable to "curses.a".

    My environment is dosbox-staging. I've set "LFN=n" in djgpp.env as
    DOSBox doesn't have LFN support (at least not this fork of it). There
    are no long filenames involved here anyway.

    I hope that's a useful enough error report. Please let me know if I
    can provide any more information.

    Jamie
    OFYI, after having installed DOSBox I was able to reproduce the bug.
    What the maintariners of binutils have changed between bnu2351b and
    bnu237b is completely unknown to me. It seems to be a DOSBox specific
    issue and AFIAK DOSBox has never been recommended to be used as DJGPP development environment. I will try to investigate this issue when I
    have enough time. This will not be quite soon.

    Use bnu2351b; AFAIK there are no DJGPP specific changes between
    bnu2351b and bnu237b.


    Regrads,
    Juan M. Guerrero

    I'm also unable to reproduce this in a DOS 6.22 virtual machine. I
    agree it's a DOSBox-specific issue.

    Thinking about DOSBox limits, there are a hard-coded number of FILES
    and FCBs, I thought maybe ar has generally changed the way it reads
    input files and is hitting a limit. However, trying the DOSBox-X fork
    which allows these to be configured, FILES=10 produced a different
    more specific error "ar: Too many open files (EMFILE)" so at least a
    file limit doesn't appear to be the problem.

    Thank you for your time testing. I agree there's no rush to fix it and
    DOSBox isn't such a great environment for DJGPP anyway.

    It's possible to work around this with a DOS VM (probably FreeDOS
    too), or cross-compile on Linux, or just use bnu2351b in DOSBox.
    That's plenty of valid alternatives.

    Jamie

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to All on Sun Jan 2 13:48:57 2022
    Am Sat, 1 Jan 2022 17:30:43 -0800 (PST)
    schrieb "Jamie Bainbridge (jamie.bainbridge@gmail.com) [via
    djgpp@delorie.com]" <djgpp@delorie.com>:

    On Sunday, 2 January 2022 at 9:01:39 am UTC+10, Juan Manuel Guerrero (juan.guerrero@gmx.de) [via djgpp@delorie.com] wrote:
    Am Fri, 31 Dec 2021 20:03:57 -0800 (PST)
    schrieb "Jamie Bainbridge (jamie.ba...@gmail.com) [via
    dj...@delorie.com]" <dj...@delorie.com>:
    Hello,

    Compiling the PDCurses-3.9 source with the latest binutils
    (bnu237b) fails to create the library file with:

    ar: curses.a: invalid operation

    You can also reproduce the same error easily with the same
    command manually:

    ar rcv curses.a *.o

    ar makes a small 8-byte curses.a file but that's obviously not
    valid.

    Trying several previous versions (bnu232b, bnu234b, bnu2351b)
    with the same compiled object files all work fine.

    I'm compiling the latest stable PDCurses from upstream: https://github.com/wmcbrine/PDCurses/releases/tag/3.9

    The only change I've made is to add -DPDC_RGB to CFLAGS and
    change the LIBCURSES variable to "curses.a".

    My environment is dosbox-staging. I've set "LFN=n" in djgpp.env
    as DOSBox doesn't have LFN support (at least not this fork of
    it). There are no long filenames involved here anyway.

    I hope that's a useful enough error report. Please let me know if
    I can provide any more information.

    Jamie
    OFYI, after having installed DOSBox I was able to reproduce the
    bug. What the maintariners of binutils have changed between
    bnu2351b and bnu237b is completely unknown to me. It seems to be a
    DOSBox specific issue and AFIAK DOSBox has never been recommended
    to be used as DJGPP development environment. I will try to
    investigate this issue when I have enough time. This will not be
    quite soon.

    Use bnu2351b; AFAIK there are no DJGPP specific changes between
    bnu2351b and bnu237b.


    Regrads,
    Juan M. Guerrero

    I'm also unable to reproduce this in a DOS 6.22 virtual machine. I
    agree it's a DOSBox-specific issue.

    Thinking about DOSBox limits, there are a hard-coded number of FILES
    and FCBs, I thought maybe ar has generally changed the way it reads
    input files and is hitting a limit. However, trying the DOSBox-X fork
    which allows these to be configured, FILES=10 produced a different
    more specific error "ar: Too many open files (EMFILE)" so at least a
    file limit doesn't appear to be the problem.

    Thank you for your time testing. I agree there's no rush to fix it and
    DOSBox isn't such a great environment for DJGPP anyway.

    It's possible to work around this with a DOS VM (probably FreeDOS
    too), or cross-compile on Linux, or just use bnu2351b in DOSBox.
    That's plenty of valid alternatives.

    Jamie


    To finish this issue, I have installed MSDOS 6.22 and FreeDOS 1.3RC5
    on VirtualBOX and compiled the DJGPP port of PDCurses-3.9 (aka
    pdcur39s.zip) and I have expirienced no issues at all. All the test
    programs of PDCurses-3.9 run flawlessly. The port itself is OK and has
    been used to create the DJGPP port of lynx (aka l290d10b.zip). Both
    ports have been created using bnu237b.

    It seems to be an DosBOX issue that I will investigate ASAP, but to be
    honest I am not aware of any DJGPP specific reason that justifies the
    update from bnu2351b to bnu237b. So if some one preferes to use DosBOX
    as development environment for DJGPP, then there is no reason at all to
    use bnu237b instead of bnu2351b, especially if he uses gcc346b.zip like
    me.

    Regards,
    Juan M. Guerrero

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