This is the mail archive of the cygwin@sourceware.cygnus.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Troubles with DLL's


Hi,
root@jacob.remcomp.fr wrote:
> Nobody answered that message.

Nobody answered that message here in the mailing list, but two tried to help
me with via mail.
OK, Mikey was right to point me, that I should read the web page, where I
got the Makefile.Dlls more carefully. Actually, I cannot find the url. Can
somebody post it?

Unfortunatelly the intermediate files like dll1_globals.h dll1_dll.h
dll2.def are always deleted after make the 'all' target finished in my
samples, so I'd never seen these files. In the Makefile, which includes
Makefiles.Dlls I had to insert a line like this:
.SECONDARY: dll1_globals.h dll1_dll.h dll2_globals.h dll2_dll.h

He also pointed out, that I have to access the data, via label, how it is
defined in the DLL not directly (although it appear as exported symbol), but
through a pointer imp_label, which has been created by a bunch of binary and
shellscript tools or special Makefile templates. After playing 4 hours with
it - still not working - I found, that the set of image base addresses I
used on my machine does not work. With another set of image base addresses
exporting data works.

Beside these troubles, there is still a problem with creating relocatable
dlls.

Dlls with fix image base makes no sense to me: This would be like writing
very old fashioned TSR's for DOS, maybe on another level, but with the same
problems.


I've created 3 test package for the static/global data problem.

The first uses Makefile.Dlls (which is a little modified version of the
Makefile.Dlls which can be found on a web side) send me by Mikey.

The second use a shell script 'umakedll', which comes from Kees van Veen.

Third test package is based on cygshared, a script where I put all some
additionally features. Type cygshared without arguments for a short
description.

If you compile the files, testdll1.exe should work ok, including accessing
global dll data from the exe.

dlltest2, which links 2 dll's with the same image base address, NT claims,
that application cannot be initialized properly. Sometimes (I haven't
figured out, in which cases), the program starts, but if it tries to access
static/global data inside the dll2foo() the program terminates with SIGSEGV.
Loaded in gdb, you can see, that the address of the static/global data is
either out of range of the image address or only with some bytes offset.

dlltest3, including in test package  'mikey' and 'roger' (there is no
support for it in 'kees') is based on the same code, but use another image
base address for dll2.
This test should also work fine:
                                There is a problem with relocating dll's!

dlltest4 (and following) is only included in the package 'roger', because
this doesn't work with 'mikey' and 'kees'.
In this test I link dlltest4 to dll3 and dll2a. dll3 is also linked to
dll2a. I have to modify the generation of dll_entry@12 to
${libname}_dll_entry@12, otherwise linking dll3 to libdll3_dll.a doesn't
know which exported function 'dll_entry@12' it should use to link. Actually,
I don't think, that it make much sense, that the function dll_entry@12 makes
much sense insite the libdll_dll.a.
This test should also work, because dll3 and dll2a uses different image base
addresses.
 dlltest5-dlltest7 are modification of previous test, look in the Makefile.

I use latest (I think) coolview and the linker from an archive
'B18-patched-ld'.
I use NT4 Server, SP3, PP200 64MB as plattform. I haven't tested it with
Windows 95.

Another issue:
I try to compile a little more complex dll. If it starts linking (linking as
whole, including dlltool, ld and other), it is a hard stress test for my HD.
Although my Atlas II is really not slow, I can do now much more, than just
drinking a coffee while waiting for finishing.
The solution (even if it works, with a set of image bases) is not very
handy.
I'm also not very happy with using global #defines to access
dll_global_symbol via _imp__dll_global_symbol, because this label can also
be used in the exe-sources in another scope, as local variable, struct/class
member element,etc.

Roger



Mikey.zip

Kees.zip

Roger.zip


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]