More Cygwin breakage

[Steven Edwards]

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

[Dmitry Timoshkov]

"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.

[Robert Shearman]

> 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

Why not just change winebuild to do something like this:
#ifdef BROKEN_MINGW_LD
	print_normal(...);
#else
	print_noname(...);
#endif

Rob

[Uwe Bonnes]

> > > > > "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. [phone] -------- Fax. [phone] ----------

[Dmitry Timoshkov]

"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.

[Alexandre Julliard]

"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

[Dmitry Timoshkov]

"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.

More cygwin breakage

[Christopher Faylor]

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

More cygwin breakage

[Steven Edwards]

--- 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

More cygwin breakage

[Dmitry Timoshkov]

"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.

More cygwin breakage

[Christopher Faylor]

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