From tonyg Fri Sep 24 23:53:24 1999
Subject: egcs/mingw32 - dllwrap - error code 127?
To: khan@xraylith.wisc.edu
Date: Fri, 24 Sep 1999 23:53:24 +1200 (NZST)
X-Mailer: ELM [version 2.5 PL0pre8]
Content-Length: 4201      
Status: RO

Hi Mumit.

Sorry to bother you, but I've exhausted *all* other areas where I
might find an answer to my problem. There doesn't seem to be an answer
out there - and it could well be compiler-related.

First I'd like to thank you for taking the considerable time and
effort to port egcs to mingw32! (After a couple of weeks development
for Win32 I am getting a feel for how much of a challenge it must have
been... :-( )

I am developing an app which runs on both Linux and Win32, using your
mingw32 port of egcs. It uses plugins to provide features, and I chose
to use gmodule (part of glib, used by GTK+ etc) for a portable DLL/.so
API library.

The problem I'm having is that occasionally I get the following
strange sequence of events:

* compiling and linking works FINE. No error messages, no warnings, nothing
  abnormal.

* For no apparent reason, one of the plugin DLLs will break and
  consistently refuse to load, citing "Error code 127" which as far as
  I can tell means ERROR_PROC_NOT_FOUND. MS's help databases online offer
  very little else about this error code :-/

This happened twice across the space of about two weeks - the
workaround seems to be to **RENAME** the offending DLL to something
else entirely! (by which I mean rename the .c file and alter the
makefile too)

For instance:

* I had a DLL called numseq.c which exhibited this problem. It was
  not structurally any different to the other plugin DLLs in
  the system. It worked 100% on Linux.
* Every time I launched the application, it complained about that specific
  DLL - error code 127
* Renaming numseq.c to seqnum.c and recompiling to seqnum.dll fixed the
  problem! No changes to the source code (other than renaming the entrypoint
  to my code from "init_plugin_numseq" to "init_plugin_seqnum")!

(For the record, it was definitely the LoadLibrary() call that was
failing - the gmodule source code is unambiguous.)

I've looked at all the examples you have made available on the
xraylith site. I've searched the net many times for error code 127
relating to DLL loading (mingw32 or not). I read as much of MS's
poorly-indexed documentation from msdn.microsoft.com as I could
find. I tried changing all *sorts* of things that shouldn't have
caused problems but just might on an MS OS:

* I copied another plugins' source code over into the file named numseq.c -
  it compiled OK (as expected) but still refused to load: error code 127.
* I emptied the file completely, except for an empty init_plugin_numseq().
  It still didn't work.
* I copied another *DLL* file over numseq.dll. It *still* gave error 127 -
  even though the other DLL worked fine under its own name!
* I ran scandisk, to see if it was the directory entry at fault. Still no
  joy.

So it really seems to be the name of the DLL causing problems. For the record,
the two files I've had trouble with so far have been called:

	numseq.c ==> numseq.o ==> numseq.dll
	vco.c ==> vco.o ==> vco.dll

and the invocation of dllwrap I used was:

%.dll: %.o dllinit.o
	dllwrap -s --export-all -o $@ $< ../src/galan.lib $(LIBS) dllinit.o

(where $(LIBS) was the same for all plugins, galan.lib contains the
stubs for the core routines in my app, removing the "-s" didn't make
it better, and dllinit.o is from dllinit.c, supplied by you in the
dlltools add-on package for egcs.)

It might also help to mention I'm running Windows 95a. I don't have
access to any other systems to try compiling on, I'm afraid :-(

Anyway, to sum up (hope you're still with me!) I'm at a complete loss
for what to do next. Have you *ever* seen anything remotely like this
before? Have you any suggestions? Should I file a bug report with MS?
(ha! as if anything would come of *that*... :-) )

If you can think of anyone or anywhere I'd be better contacting
regarding this problem, please let me know.

Thanks once more,
Yours more-or-less-resignedly,
  Tony Garnock-Jones

PS if you need to, see http://homepages.ihug.co.nz/~surazal/ to find
the code that I'm talking about.