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

[Jamie Bainbridge]

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

[Juan Manuel Guerrero (juan.guerrero@gmx.de) [via djgpp@delorie.com]]

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,

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

[Juan Manuel Guerrero (juan.guerrero@gmx.de) [via djgpp@delorie.com]]

Am Fri, 31 Dec 2021 20:03:57 -0800 (PST)
schrieb "Jamie Bainbridge (jamie.ba...@gmail.com) [via
dj...@delorie.com]" <dj...@delorie.com>:

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

[Jamie Bainbridge]

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

[Juan Manuel Guerrero (juan.guerrero@gmx.de) [via djgpp@delorie.com]]

Am Sat, 1 Jan 2022 17:30:43 -0800 (PST)

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