The 'normal' vars don't seem to have a problem, but dereferencing
that particular pointer results in a page fault:

Well, I was very very wrong:

I added some debug printf() statements to a simple program, so that
it prints the values of certain variables exported by the library :

UBYTE md_volume : 233 (0xe9) --- should have been 128
UBYTE md_musicvolume : 233 (0xe9) --- should have been 128
UBYTE md_sndfxvolume : 233 (0xe9) --- should have been 128
UBYTE md_reverb : 233 (0xe9) --- should have been 0
UBYTE md_pansep : 233 (0xe9) --- should have been 128
UWORD md_mixfreq : 44100
UWORD md_mode : 63977 (0xf9e9) --- should have been 0x110F
UWORD md_device : 9705 (0x25e9) --- should have been ???
MDRIVER* md_driver : 0xcea27e9
CHAR* md_driver->Name: [crash...]

Note that all of those values have 0xe9 - except for md_mixfreq to
which I do assign 44100. 0xe9 (i.e.: jmp) seems to be coming from dlstatbind(): https://www.delorie.com/bin/cvsweb.cgi/djgpp/src/libc/dxe/dxe3stat.c?rev=1.1

Looks like exported variables support in import libraries is very
much broken?

I believe this is because of how variables are exported (as opposed to functions).

Things are quite foggy after all those years, but for COFF, you are actually getting a _pointer_ to a variable. That is, in your case a _pointer_ to the desired pointer (that's why having a getter for the pointer solves it). I know this is *not* how it works when you are compiling statically, but it is a limitation of the executable format. I also think this limitation applies to the original DXE (as designed by Charles W Sandmann) not only for my
DXE3. BTW, the COFF used by DJGPP is not even Windows COFF.

TL;DR: you have to dereference that pointer twice. I am not sure it can be handled transparently as long as DJGPP was COFF-based.

That's why I "invented" DJELF back then. The ELF executable format has a special kind of relocation (perhaps it was called R_<arch>_COPY or something like that) which would solve this issue magically, but then you are restricted to ELF.

-dborca