Hola and Thanks for everything so far in getting the Mingw port rolling.
Doing my work on getting shlwapi.dll built I noticed the missing imports from user32 wvsnprintfA@16 and wvsnprintfW@16 in libuser32.a. I was going to submit a patch to the mingw developers for the Win32api package that updates the libuser32.a and I am still planning on doing that but I think a more self-contained solution would be better.
In the ReactOS tree we have a "make implib" rule to generate all of the import Libs for our shared libs. This way we are not dependant on the mingw win32api. I think the wine tree needs to do something similer. Once this is done we can go ahead and build the import libs for ntdll, msvcrt and User32 that are needed for the wine dlls.
The command line is something like this dlltool --as=as --dllname user32.dll --def user32.spec.def --output-lib libuser32.a
The only real problem isnt really a problem but we just wouldn't catch it in the build processes. If WINES libuser32.a exported a non-win32 function that we shouldn't Use anyway and another dll imported that function (see comctl32) like GetSysColorPen (see wine/windows/syscolor.c line 388) The build would still work and we wouldn't catch it untill someone tries to use comctl32.dll without wines user32.dll.
I still think the change would be for the better and request your comments.
Thanks Steven
"Every revolution was once a thought in one man's mind" - Ralph Waldo Emerson
"Steven Edwards" Steven_Ed4153@yahoo.com writes:
The only real problem isnt really a problem but we just wouldn't catch it in the build processes. If WINES libuser32.a exported a non-win32 function that we shouldn't Use anyway and another dll imported that function (see comctl32) like GetSysColorPen (see wine/windows/syscolor.c line 388) The build would still work and we wouldn't catch it untill someone tries to use comctl32.dll without wines user32.dll.
That's the main problem. I'm not opposed to having a way of building import libraries for Wine, but I think the default should be to not use them, otherwise we won't find such problems. And the GetSysColorPen and wvsprintf exports really need to be fixed if we ever want to use Wine dlls under Windows.
Ok I will hold off on a patch for a implib rule untill the new binutils Is released. I can do without it for now away, as there are still like 50 other misc bugs that we can hunt down and only 4 or 5 dlls need the Ntdll and shlwapi import libs. Like I said its manly something that would Be nice to have and not required at this point.
Thanks Steven
"Every revolution was once a thought in one man's mind" - Ralph Waldo Emerson
"Steven Edwards" Steven_Ed4153@yahoo.com wrote:
In the ReactOS tree we have a "make implib" rule to generate all of the import Libs for our shared libs. This way we are not dependant on the mingw win32api. I think the wine tree needs to do something similer. Once this is done we can go ahead and build the import libs for ntdll, msvcrt and User32 that are needed for the wine dlls.
The command line is something like this dlltool --as=as --dllname user32.dll --def user32.spec.def --output-lib libuser32.a
I would recommend the following command lines to build both import library and dll with *correct* import/export tables:
DLLWRAPFLAGS = -mno-windows -k --def $(MODULE).spec.def -Wl,--kill-at,--enable-stdcall-fixup
(probably --enable-stdcall-fixup is now obsoleted by recent winebuild changes)
$(RM) $(TOPOBJDIR)/dlls/lib$(MODULE).a $(DLLWRAP) $(DLLWRAPFLAGS) $(ALL_OBJS) -o $@ $(IMPORTS:%=-L$(DLLDIR) -l%) $(ALL_LIBS) $(DLLTOOL) --kill-at --input-def $(MODULE).spec.def --output-lib lib$(MODULE).a $(CP) lib$(MODULE).a $(TOPOBJDIR)/dlls/lib$(MODULE).a
You need dlltool from binutils CVS because my fix regarding decorated/non-decorated imports/exports haven't found its way to 2.12 yet. This fix allows to not require to have *two* .def file sets (with decorated and non-decorated exports as in ReactOS).
Also, since $(MODULE) has an extension included now, you need some workaround for this.
-
Alexandre Julliard -
Dmitry Timoshkov -
Steven Edwards