So here's the story of the past few hours of my life. Sorry for the blogish nature of this post. First, I wanted to test the previous hypothisis that dll.exp was somehow being mistranslated as a link to dll.exp.dll (which is the DLL the popup message claims is missing). So I changed dlltool's output name to be 'export.o' instead of 'dll.exp' (dlltool's man page shows the export file given a .o extention, so the change from .exp -> .o shouldn't be a problem) and then modified the build command similarly. This still gave the same error message, so I threw out that theory. Next, I wanted to see if it was the created gtk+.dll file that directly had the dependency to dll.exp.dll, or if it was a dependency of a dependency. Each dependency of a DLL file is listed in its PE header. Essentially, I needed ldd, but for Win32 executables instead of *nix. I managed to track down such a program (time-limited shareware, but oh well) and found that dll.exp.dll was a direct dependency of gtk+.dll. I also confirmed that dll.exp.dll did not show as a dependency for the glib.dll that was created for the Glib Perl module. As a possible work-around, I tried to create a dummy dll.exp.dll. I created a dummy.c program that had the function boot_exp(), which should be enough to get a working DLL. Then I copied the gtk2.def and modified it so the only export would be boot_exp() (with _boot_exp() as an alias, as my understanding is that this is suggested for compatibility with multiple compilers). Then I created the dll with: ---- gcc -c dummy.c dlltool --def dummy.def -e dummy.exp g++ -o dll.exp.dll dummy.o dummy.exp ---- This was enough to make the popup error message go away, but there was still an error from DynaLoader about not being able to load all its required files. I didn't want to spend a lot of time on a cheap hack, so I stopped this approach. Next attempt was to trim down the build command to the bare minimum needed to get a DLL compiled. I trimmed off all the .o files except Gdk.o, and modified the gtk+.def file so that the only symbol exported was 'boot_gdk' (and its alias '_boot_gdk'). The resulting DLL still had the dependency to dll.exp.dll. After putting back all the .o files and returning the orginal .def, I removed the .a files one at a time, replacing the last file removed after each go. Still saw the dll.exp.dll dependency for each one removed. I didn't get any linking errors until I removed libperl58.a. So I removed all the .a files except that one, and still saw the dll.exp.dll dependency. I also took out libperl58.a and put it the path to perl58.dll. This was enough to get it to link without error, but still showed the evil dependency. I'd like to try modifying the DLL to manually remove the dependency, but I haven't yet figured out how to do that, and it would only be another cheap hack.
Attachment:
pgpJjIe7DNMzC.pgp
Description: PGP signature