Dynamic link libraries in DOS
Re: Dynamic link libraries in DOS
I have kept a copy of all of them, I can upload it
Re: Dynamic link libraries in DOS
Here is the dynamic link file: https://ufile.io/aejmc
And here is the thread patch: https://ufile.io/cpavi
And here is the thread patch: https://ufile.io/cpavi
Re: Dynamic link libraries in DOS
This actually does now "mostly" seem to work with latest DJGPP BinUtils, but I wouldn't forcibly rely on it.rugxulo wrote:Last I checked, this wasn't supported by BinUtils on any COFF targets, so that won't work here. MS COFF is probably the only COFF target that will get any work done in the future, due to Windows popularity (as Cygwin and MinGW are tier two). But even that isn't "top tier" for GCC / BinUtils developers. They mostly only focus on ELF and consider COFF (and others?) as heavily deprecated (and even COFF "-gcoff" debugging since GCC 4.5.x seems broken, at least for DJGPP, in lieu of newer DWARF, e.g. v4, which is heavily favored these days).marcov wrote:So that probably precludes any dead code removal options (--gc-sections and friends on gcc) too.
Re: Dynamic link libraries in DOS
I tried a simple dll example, and it did work. I am updating the the 1.06 release to include dxe3gen.exe.
I'm using files (binaries) readily available from djgpp mirrors.
Besides that, there are some improvements to the feature that could be made:
- documentation
- fbc -dll fileX.bas creates fileX_li.a but my ld looks for libfileX.a
- statically linking will cause crash on exe load. A call to dylibopen() is needed to initialize the export table
- rebuilding libfb.a due to change in symb_reg.txt, mimimally should only need to touch src/rtlib/dos/sys_dylib.c and re-add sys_dylib.o
- or possibly, put the export table in it's own object module, that gets built and linked separately from libfb.a (but added automatically to the ld command line)
I'm not going to try and fix or change before next release.
I'm using files (binaries) readily available from djgpp mirrors.
Besides that, there are some improvements to the feature that could be made:
- documentation
- fbc -dll fileX.bas creates fileX_li.a but my ld looks for libfileX.a
- statically linking will cause crash on exe load. A call to dylibopen() is needed to initialize the export table
- rebuilding libfb.a due to change in symb_reg.txt, mimimally should only need to touch src/rtlib/dos/sys_dylib.c and re-add sys_dylib.o
- or possibly, put the export table in it's own object module, that gets built and linked separately from libfb.a (but added automatically to the ld command line)
I'm not going to try and fix or change before next release.