From: Aaron W. L. <aar...@aa...> - 2004-09-05 22:44:44
|
Carlo Wood wrote: > As far as I know, a .def file is only used when you create > an import library. I don't understand why you are talking > about two different .def files. DEF files are also used to create EXP files and DLLs (which is what the internal name functionality is primarily used for). See MS LINK documenation for details. As mentioned in my other post--which I'd like you to respond to--I don't think the DEF internal name should have any affect on import library generation. Aaron W. LaFramboise |
From: Carlo W. <ca...@al...> - 2004-09-05 22:49:36
|
My comment in more detail... On Sun, Sep 05, 2004 at 09:38:03PM +0200, Hartmut Birr wrote: > Currently I will build a exe/dll/driver. Which is it? A .exe, a .dll or a "driver" whatever that make be. > I know the imported dlls and its There is no such thing as "an imported dll". There is something that is called "an import library" and on mingw that has the extension .dll.a. Native (windows) import libraries have the extension ".lib". So, what do you mean here? > specifications Specification? What are that in this context? Are you refering to the .def file? > but I don't have the import library or the imported dll. The *is* no such thing as "imported dll". > The > first step is to build the import libarary. The def file contains entries > like this: > > KeRaiseIrql@8 > @KfRaiseIrql@4 Then my patch has no effect at all: there are no aliases here. (I don't think the word "alias" is correct here, but that is what most documentation refers this too (imho, the authors of those docs didn't understand what it really meant and only wrote down they THOUGHT the '=' was doing). When I say 'alias' in this context then I mean that there is an extra name and an equal sign, like this: KeRaiseIrql@8 = _KeRaiseIrql@8 @4 [flags] The @4 is the ordinal number which is not relevant here (and is optional). The 'alias' then would the "KeRaiseIrql@8" and the internal (or real .dll) name would be _KeRaiseIrql@8. > The second step is to build the exe/dll/driver. You mean, the final application or library that is calling/using functions of the other .dll that we just created the import library of? > This file is linked against > the import library. yes > The exe/dll/driver _must_ import names like this: > > KeRaiseIrql > KfRaiseIrql Fine, if you say so. You can check that for sure with the link -dump -exports thus. At least, I can on my box. > This has worked up to dlltool 2.15.90. That refers to the above? > Since dlltool 2.15.91 are the imported names: > > KeRaiseIrql@8 > @KfRaiseIrql@4 If you mean with "imported" names the internal names that are defined by the .dll - then it is not possible that they are changed by a change in dlltool. dlltool generates the import library and not the .dll, so it is not possible that whatever the .dll is defining has changed. More likely is that those two examples are the names that have ALWAYS been defined by the .dll (and would be visible with the link -dump -exported command), I'll assume that is what you mean. That means then that your previous remark was wrong (The > The exe/dll/driver _must_ import names like this: > > KeRaiseIrql > KfRaiseIrql above) Rather you mean to say there: The exported names (of the import library) must be 'KeRaiseIrql' and 'KfRaiseIrql'. However, that is weird too because that would mean the stdcall calling convention has changed... but ok. > This is wrong because the loader doesn't find this symbols in the imported > dll. If I change the names in the def file for the import library to > > KeRaiseIrql > KfRaiseIrql > > I get many link errors 'undefined reference to KeRaiseIrql@8'. What must I > change in the build process to get the old and correct behaviour? Then change the .def to read: KeRaiseIrql@8 = KeRaiseIrql @KfRaiseIrql@4 = KfRaiseIrql On the left we have the exported names that must fit the "undefined reference to KeRaiseIrql@8" errors and on the left we have the internal names that much fit the runtime "popup" error that a function could not be found in the .dll. HOWEVER. Please note that my patch does NOT change the behaviour of dlltool when you do NOT have such an '=' sign. Therefore - I don't know why you have this problem. Also, it should work the same if you use this as .def file: KeRaiseIrql@8 @KfRaiseIrql@4 And then use --kill-at with dlltool. Because then it will use those names as exported names and the same names with the '@<n>' stripped off as internal names... just as above with the explicit aliases. This is what you were doing in the past I understand - and therefore I don't understand why my patch could have any influence. Now, please read this and my previous posts very carefully so that you will understand exactly what I mean before we drift even further into misunderstandings, guessing and miscommunication regarding this. -- Carlo Wood <ca...@al...> |
From: Hartmut B. <har...@gm...> - 2004-09-05 23:55:56
|
> -----Original Message----- > From: min...@li...=20 > [mailto:min...@li...] On Behalf Of=20 > Carlo Wood > Sent: Monday, September 06, 2004 12:49 AM > To: min...@li... > Subject: Re: [Mingw-users] dlltool.c (was: Announcement:=20 > Binutils-2.15.91-20040902 1 Release candidate) >=20 >=20 >=20 > > Since dlltool 2.15.91 are the imported names: > >=20 > > KeRaiseIrql@8 > > @KfRaiseIrql@4 >=20 > If you mean with "imported" names the internal names that > are defined by the .dll - then it is not possible that they I mean the names which are stored in the import name table of the = created application. This was always correct with dlltool 2.15.90 and is wrong = with 2.15.91-20040802 =20 > are changed by a change in dlltool. dlltool generates the > import library and not the .dll, so it is not possible that > whatever the .dll is defining has changed. Dlltool has only seen a def file which contains the names with '@' and = the option --kill-at. Objdump shows for a library from dlltools 2.15.90 this output ...=20 Contents of section .idata$6: 0000 00004578 41637175 69726546 6173744d ..ExAcquireFastM 0010 75746578 0000 utex.. ... and from dlltools 2.15.91 this ... Contents of section .idata$6: 0000 00004045 78416371 75697265 46617374 ..@ExAcquireFast 0010 4d757465 78403400 Mutex@4. ... It seems, that --kill-at does not work with dlltool 2.15.91-20040802. I = get the same wrong result with dlltool 2.15.90 if the '--kill-at' option is = not used. - Hartmut |
From: Hartmut B. <har...@gm...> - 2004-09-06 09:12:46
Attachments:
dllttooltest._z_i_p_
|
Hi, I've attached a little sample which demonstrate my problem. The application imports RtlGetCurrentDirectory_U from ntdll.dll. Dlltool is used to create the import library. The application is executable if the import library was created with dlltool 2.15.90. It is not executable if dlltool 2.15.91-20040902 was used. - Hartmut |
From: Carlo W. <ca...@al...> - 2004-09-06 14:50:04
|
On Mon, Sep 06, 2004 at 11:12:26AM +0200, Hartmut Birr wrote: > Hi, > > I've attached a little sample which demonstrate my problem. The application > imports RtlGetCurrentDirectory_U from ntdll.dll. Dlltool is used to create > the import library. The application is executable if the import library was > created with dlltool 2.15.90. It is not executable if dlltool > 2.15.91-20040902 was used. > > - Hartmut Ok, the patch indeed contains a bug :/. --kill-at is always disabled now. Nevertheless, you could have noticed that it works if you add the correct internal to the .def file: RtlGetCurrentDirectory_U@8 = RtlGetCurrentDirectory_U But --kill-at should do the same. I'll submit a PR and patch to binutils. -- Carlo Wood <ca...@al...> |
From: Hartmut B. <har...@gm...> - 2004-09-06 18:22:39
|
> -----Original Message----- > From: min...@li... > [mailto:min...@li...] On Behalf Of > Carlo Wood > Sent: Monday, September 06, 2004 4:50 PM > To: min...@li... > Subject: Re: [Mingw-users] dlltool.c (was: Announcement: > Binutils-2.15.91-20040902 1 Release candidate) > > > Nevertheless, you could have noticed that it works if you add > the correct internal to the .def file: > > RtlGetCurrentDirectory_U@8 = RtlGetCurrentDirectory_U > This is wrong. The def-file describes an export section for a dll. The correct entry is: RtlGetCurrentDirectory_U = RtlGetCurrentDirectory_U@8 Dlltool _must_ use this entry for creating the import library. - Hartmut |
From: Danny S. <dan...@cl...> - 2004-09-06 19:35:36
|
----- Original Message ----- From: "Carlo Wood" | But --kill-at should do the same. I'll submit a PR and patch to binutils. | Why? With all this fuss over the broken package, no one has bothered to comment on the new package (20040904) release 48 hours later which does honour --kill-at. Danny |
From: Carlo W. <ca...@al...> - 2004-09-06 22:23:37
|
On Tue, Sep 07, 2004 at 07:30:17AM +1200, Danny Smith wrote: > > ----- Original Message ----- > From: "Carlo Wood" > > | But --kill-at should do the same. I'll submit a PR and patch to > binutils. > | > > Why? With all this fuss over the broken package, no one has bothered to > comment on the new package (20040904) release 48 hours later which does > honour --kill-at. > Danny I am not interested in what you release when the binutils is still broken. I think that binutils should contain the correct source, so that no patch is needed when you make a release for mingw. -- Carlo Wood <ca...@al...> |
From: Carlo W. <ca...@al...> - 2004-09-06 22:40:44
|
> On Tue, Sep 07, 2004 at 07:30:17AM +1200, Danny Smith wrote: > > Why? With all this fuss over the broken package, no one has bothered to > > comment on the new package (20040904) release 48 hours later which does > > honour --kill-at. > > Danny I looked at the .diff on SF and it doesn't change dlltool.c at all. I cannot test it though because binutils-2.15.91-20040904-1.tar.gz is not readable or something: this file is on none of the download mirrors. -- Carlo Wood <ca...@al...> |
From: Danny S. <dan...@cl...> - 2004-09-06 23:16:07
|
----- Original Message ----- From: "Carlo Wood" < | On Tue, Sep 07, 2004 at 07:30:17AM +1200, Danny Smith wrote: | > | > ----- Original Message ----- | > From: "Carlo Wood" | > | > | But --kill-at should do the same. I'll submit a PR and patch to | > binutils. | > | | > | > Why? With all this fuss over the broken package, no one has bothered to | > comment on the new package (20040904) release 48 hours later which does | > honour --kill-at. | > Danny | | I am not interested in what you release when the binutils is still broken. For the record, it's not. | I think that binutils should contain the correct source, so that no patch | is needed when you make a release for mingw. For the record, that is where it is fixed. Danny | | -- | Carlo Wood <ca...@al...> | |
From: Carlo W. <ca...@al...> - 2004-09-07 01:00:25
|
On Tue, Sep 07, 2004 at 11:10:50AM +1200, Danny Smith wrote: > For the record, that is where it is fixed. > Danny Ah ok. I thought it was your doing. Well - then everything is fine now as far as me is concerned. I think I am going to concentrate on my next problem: adding win32 support to libevent :/ -- Carlo Wood <ca...@al...> |
From: Carlo W. <ca...@al...> - 2004-09-06 22:49:07
|
On Tue, Sep 07, 2004 at 07:30:17AM +1200, Danny Smith wrote: > comment on the new package (20040904) release 48 hours later which does > honour --kill-at. > Danny I looked at the source code itself now, and you are doing: char const* internal_name = exp->internal_name != exp->name ? exp->internal_name : xlate (exp->name); That is indeed a fix for the bug that I introduced. Thanks. But apart from this fix - Aaron claims that dlltool must not use the right hand side of the '=' in a .def file at all. I am still not convinced about that. I think that the RHS *is* the internalname, and that the internal name is what is used in the .dll source. -- Carlo Wood <ca...@al...> |
From: Carlo W. <ca...@al...> - 2004-09-06 11:22:49
|
On Mon, Sep 06, 2004 at 01:55:26AM +0200, Hartmut Birr wrote: > > > Since dlltool 2.15.91 are the imported names: > > > > > > KeRaiseIrql@8 > > > @KfRaiseIrql@4 > > > > If you mean with "imported" names the internal names that > > are defined by the .dll - then it is not possible that they > > I mean the names which are stored in the import name table of the created > application. The created application has nothing to do with dlltool. dlltool is used to generate the import library, not the application. > Dlltool has only seen a def file which contains the names with '@' and the > option --kill-at. Objdump shows for a library from dlltools 2.15.90 this ^^^^^^^^^^^^^ You are too unclear. What do you mean with "a library"? Man, mention the FILE you are working on! I am stopping with guessing what you mean until I finished the other threads and feel secure again about how things work. > output > > ... > Contents of section .idata$6: > 0000 00004578 41637175 69726546 6173744d ..ExAcquireFastM > 0010 75746578 0000 utex.. > ... > > and from dlltools 2.15.91 this > > ... > Contents of section .idata$6: > 0000 00004045 78416371 75697265 46617374 ..@ExAcquireFast > 0010 4d757465 78403400 Mutex@4. > ... > > It seems, that --kill-at does not work with dlltool 2.15.91-20040802. I get > the same wrong result with dlltool 2.15.90 if the '--kill-at' option is not > used. And how does the .def file look like that you used? Because this 100% and only depends on the .def file! I've already explained this four times now and get the idea it makes no sense to repeat it. There are clearly two possibilities: 1) You are NOT using aliases in the .def file. In that case my patch has no influence. 2) You ARE using aliases, in that case the patch has as result that --kill-at is ignored as means to generate the internal name, and the specified two names in the .def file are used instead. So, if in that case "it doesn't work" then you are using the wrong .def file! -- Carlo Wood <ca...@al...> |
From: Danny S. <dan...@cl...> - 2004-09-04 20:30:48
|
----- Original Message ----- From: "Carlo Wood" | On Sat, Sep 04, 2004 at 06:51:32PM +1200, Danny Smith wrote: | > | > ----- Original Message ----- | > From: "Carlo Wood" | > | Are you sure the .def file doesn't contain explicit aliases? | > | I recently submitted a patch for dlltool that change the | > | behaviour a bit (actually correction wrong behaviour). | > | | > | > Have a look at line 903 in dlltool.c and see why implibs are broken | > now. | > Danny | | I'd like to, but I cannot find the binutils that you put on SF. | Where did you put it? I;ve hidden until I can release a fixed version. Danny | | -- | Carlo Wood <ca...@al...> | | | ------------------------------------------------------- | This SF.Net email is sponsored by BEA Weblogic Workshop | FREE Java Enterprise J2EE developer tools! | Get your free copy of BEA WebLogic Workshop 8.1 today. | http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click | _______________________________________________ | MinGW-users mailing list | Min...@li... | | You may change your MinGW Account Options or unsubscribe at: | https://lists.sourceforge.net/lists/listinfo/mingw-users |