More Cygwin breakage
Hello, The getopt patch works great. I can build most of the dlls now except I am getting this error in comctl32. Maybe its related? Or could it be from the new winebuild changes? This is from current CVS. Thanks Steven dllwrap -k --def comctl32.spec.def -o comctl32.dll rsrc.res.o animate.o comboex. o comctl32undoc.o commctrl.o datetime.o draglist.o flatsb.o header.o hotkey.o im agelist.o ipaddress.o listview.o monthcal.o nativefont.o pager.o progress.o prop sheet.o rebar.o smoothscroll.o string.o status.o tab.o toolbar.o tooltips.o trac kbar.o treeview.o updown.o comctl32.dll.dbg.o -L../../dlls -lwinmm -luser32 -lg di32 -ladvapi32 -lkernel32 -L../../libs/wine -lwine -L../../libs/unicode -lwine_ unicode -L../../libs/port -lwine_port -lm comctl32.exp(.edata+0x6ac):fake: undefined reference to `f1' comctl32.exp(.edata+0x6b0):fake: undefined reference to `f2' comctl32.exp(.edata+0x6b4):fake: undefined reference to `f3' comctl32.exp(.edata+0x6b8):fake: undefined reference to `f4' comctl32.exp(.edata+0x6bc):fake: undefined reference to `f5' comctl32.exp(.edata+0x6c0):fake: undefined reference to `f6' comctl32.exp(.edata+0x6c4):fake: undefined reference to `f7' collect2: ld returned 1 exit status dllwrap: gcc exited with status 1 make: *** [comctl32.dll] Error 1 __________________________________ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools
"Steven Edwards" <steven_ed4153(a)yahoo.com> wrote:
comctl32.exp(.edata+0x6ac):fake: undefined reference to `f1' comctl32.exp(.edata+0x6b0):fake: undefined reference to `f2' comctl32.exp(.edata+0x6b4):fake: undefined reference to `f3' comctl32.exp(.edata+0x6b8):fake: undefined reference to `f4' comctl32.exp(.edata+0x6bc):fake: undefined reference to `f5' comctl32.exp(.edata+0x6c0):fake: undefined reference to `f6' comctl32.exp(.edata+0x6c4):fake: undefined reference to `f7' collect2: ld returned 1 exit status dllwrap: gcc exited with status 1 make: *** [comctl32.dll] Error 1
Apparently it's a bug in dlltool (or ld) which can't handle forwards with NONAME modifier like this one: DrawTextWrap(a)20=user32.DrawTextW @415 NONAME A workaround is to create a thunk in the code like it was done before the following patch: http://cvs.winehq.org/patch.py?id=11142 -- Dmitry.
Apparently it's a bug in dlltool (or ld) which can't handle forwards with NONAME modifier like this one:
DrawTextWrap(a)20=user32.DrawTextW @415 NONAME
A workaround is to create a thunk in the code like it was done before the following patch:
Why not just change winebuild to do something like this: #ifdef BROKEN_MINGW_LD print_normal(...); #else print_noname(...); #endif Rob
"Robert" == Robert Shearman <R.J.Shearman(a)warwick.ac.uk> writes:
>> Apparently it's a bug in dlltool (or ld) which can't handle forwards >> with NONAME modifier like this one: >> >> DrawTextWrap(a)20=user32.DrawTextW @415 NONAME >> >> A workaround is to create a thunk in the code like it was done before >> the following patch: >> >> http://cvs.winehq.org/patch.py?id=11142 Robert> Why not just change winebuild to do something like this: #ifdef Robert> BROKEN_MINGW_LD print_normal(...); #else print_noname(...); Robert> #endif What about fixing MingW? -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
"Uwe Bonnes" <bon(a)elektron.ikp.physik.tu-darmstadt.de> wrote:
Robert> Why not just change winebuild to do something like this: #ifdef Robert> BROKEN_MINGW_LD print_normal(...); #else print_noname(...); Robert> #endif
What about fixing MingW?
Of course that's a preferrable solution, but unfortunately not a trivial one. I fixed a similar bug in dlltool some time ago and know what I'm talking about. Thunks in the code is a more natural solution, we already were doing something like that in different places of Wine. -- Dmitry.
"Dmitry Timoshkov" <dmitry(a)baikal.ru> writes:
Of course that's a preferrable solution, but unfortunately not a trivial one. I fixed a similar bug in dlltool some time ago and know what I'm talking about.
That doesn't mean it shouldn't be fixed. Sure someone will have to do that work, but it's much better than hiding the problem by adding extra code to Wine. -- Alexandre Julliard julliard(a)winehq.org
"Alexandre Julliard" <julliard(a)winehq.org> wrote:
That doesn't mean it shouldn't be fixed. Sure someone will have to do that work, but it's much better than hiding the problem by adding extra code to Wine.
Just to make you all know: I've found and fixed a bug in dlltool preventing exporting non-named and forwarded DLL entries. The patch is attached. Changelog: 2004-02-22 Dmitry Timoshkov <dmitry(a)baikal.ru> * dlltool.c (gen_exp_file): Even not named exported entries need a name in the Export Name Table in the case case they are forwarded to a name in another DLL. Here is a simplest test case which shows a problem: --- test.def -- LIBRARY test.dll EXPORTS exported_api=kernel32.GetVersion @1 NONAME --- EOF --- $>dllwrap --def test.def -o test.dll test.exp(.edata+0x34):fake: undefined reference to `f1' collect2: ld returned 1 exit status dllwrap: gcc exited with status 1 -- Dmitry.
On Sun, Feb 22, 2004 at 01:13:38AM +0800, Dmitry Timoshkov wrote:
I've found and fixed a bug in dlltool preventing exporting non-named and forwarded DLL entries.
The patch is attached.
Changelog: 2004-02-22 Dmitry Timoshkov <dmitry(a)baikal.ru>
* dlltool.c (gen_exp_file): Even not named exported entries need a name in the Export Name Table in the case case they are forwarded to a name in another DLL.
This fix looks reasonable. I've checked it in with some minor formatting tweaks and a new changelog. Thanks. cgf
--- Christopher Faylor <cgf(a)redhat.com> wrote:
On Sun, Feb 22, 2004 at 01:13:38AM +0800, Dmitry Timoshkov wrote:
I've found and fixed a bug in dlltool preventing exporting non-named and forwarded DLL entries.
The patch is attached.
Changelog: 2004-02-22 Dmitry Timoshkov <dmitry(a)baikal.ru>
* dlltool.c (gen_exp_file): Even not named exported entries need a name in the Export Name Table in the case case they are forwarded to a name in another DLL.
This fix looks reasonable. I've checked it in with some minor formatting tweaks and a new changelog.
Thanks.
cgf
__________________________________ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools
"Christopher Faylor" <cgf(a)redhat.com> wrote:
This fix looks reasonable. I've checked it in with some minor formatting tweaks and a new changelog.
Thank you very much for such a quick response. Could you please also have a look at the .def file parser used by dlltool and probably add support for PRIVATE keyword? Currently statements like the following one: EXPORTS DllGetClassObject(a)12=SHELL32_DllGetClassObject(a)12 @128 PRIVATE are not handled by dlltool at all. MSDN: The optional keyword PRIVATE prevents entryname from being placed in the import library generated by LINK. It has no effect on the export in the image also generated by LINK. Thanks again. -- Dmitry.
On Sun, Feb 22, 2004 at 06:07:22PM +0800, Dmitry Timoshkov wrote:
"Christopher Faylor" <cgf(a)redhat.com> wrote:
This fix looks reasonable. I've checked it in with some minor formatting tweaks and a new changelog.
Thank you very much for such a quick response. Could you please also have a look at the .def file parser used by dlltool and probably add support for PRIVATE keyword? Currently statements like the following one:
I'm not contemplating adding new functionality to dlltool. I don't use it very much myself and it is working fine for my limited needs. You've hit on the way to get changes into an free software project -- you provide patches. If you need more functionality then send your patch here. I should caution you that for any substantial changes you'll need to have an assignment on file with the FSF. cgf
participants (6)
-
Alexandre Julliard -
Christopher Faylor -
Dmitry Timoshkov -
Robert Shearman -
Steven Edwards -
Uwe Bonnes