On Sun, Feb 22, 2004 at 06:07:22PM +0800, Dmitry Timoshkov wrote:
>"Christopher Faylor" <[EMAIL PROTECTED]> 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
"Christopher Faylor" <[EMAIL PROTECTED]> 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 suppo
--- Christopher Faylor <[EMAIL PROTECTED]> 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 Timoshko
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 <[EMAIL PROTECTED]>
>
>* dlltool.c (gen_exp_file): Even not
"Alexandre Julliard" <[EMAIL PROTECTED]> 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 n
"Dmitry Timoshkov" <[EMAIL PROTECTED]> 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 i
"Uwe Bonnes" <[EMAIL PROTECTED]> 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 unfortuna
> "Robert" == Robert Shearman <[EMAIL PROTECTED]> writes:
>> Apparently it's a bug in dlltool (or ld) which can't handle forwards
>> with NONAME modifier like this one:
>>
>> [EMAIL PROTECTED] @415 NONAME
>>
>> A workaround is to create a thunk in the code like it wa
>
> Apparently it's a bug in dlltool (or ld) which can't handle forwards
> with NONAME modifier like this one:
>
> [EMAIL PROTECTED] @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
"Steven Edwards" <[EMAIL PROTECTED]> 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'
>
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
comb
11 matches
Mail list logo
