LFN: too many dirs open

[stsp]

Discussed in #91

^{Originally posted by j2969719 April 3, 2024}
When I try to compile freecom in dosemu (build -r russian) using both comcom32/64 as a shell for some reason I get this error:
ERROR: LFN: too many dirs open
It's strange that when using freecom, the compilation completes successfully.

[stsp]

Should now be fixed, although it
will take some time for new dj64dev
being built, and then a new comcom64
being built with it.
Fixing this on comcom32 is not possible
unless @jwt27 back-merges all the patches. :)

[jwt27]

Fixing this on comcom32 is not possible
unless @jwt27 back-merges all the patches. :)

Well, you know how I feel about diverging from upstream. And these patches are all specific to one very niche use case, which only you seem to be doing :)

Maybe it makes sense for a shell to have its own libc. You can still use the djgpp toolchain, just link with -nostdlib and provide your own libc/crt0 fork. More or less what you already did with djdev64.

Must say I'm impressed by what you accomplished with that, in such a short time. I don't think I mentioned that yet. Especially moving to ELF is a great choice, I think djgpp should have adopted that a long time ago.

[stsp]

Well, you know how I feel about diverging from upstream.

But you can sync with upstream, or?

And these patches are all specific to one very niche use case, which only you seem to be doing :)

You mean findclose() patches?
I think they are rather generic.
Just to be clear: have you looked
exactly into the patches referenced
in this ticket, or some others?
I reference them per-ticket exactly
to simplify back-merging, in case
someone wants to.

You can still use the djgpp toolchain, just link with -nostdlib and provide your own libc/crt0 fork.

You mean for comcom32?
No, this is not an option.
comcom32 is deprecated.
I only do the bits of work for it
because it is buildable from the
same source tree with comcom64.
I am not going to invest any real
efforts into it, over a few ifdefs.
If it keeps leaking ff handles in
some scenarios - fine with me. :)
I have comcom64 that doesn't.

Must say I'm impressed by what you accomplished with that, in such a short time.

It was a few years actually, but thanks! :)
Fortunately this was a second porting project
(fdpp was the first one), so in this case
I was just porting the fdpp thunking
infrastructure to djgpp most of the time,
rather than writing things from scratches.

Especially moving to ELF is a great choice, I think djgpp should have adopted that a long time ago.

It did an attempt. There is an elf32 frame-work
by Daniel Borca:
https://www.geocities.ws/dborca/djgpp/elf/djelf.html
I haven't tried that but others did -
it works. Why they didn't take it?
Well, who knows... But as it stands,
I have a chance to push dj64dev to
distros (like debian), write a 64bit extender
for DOS, and phase out djgpp entirely. :)
Writing a 64bit extender for DOS is a
culprit though.