Martin Storsjo martin@martin.st writes:
This avoids adding stray functions when using make_specfiles.
There shouldn't be any reason to do that. The parameters are here on purpose.
Martin Storsjo martin@martin.st writes:
This avoids adding stray functions when using make_specfiles.
There shouldn't be any reason to do that. The parameters are here on purpose.
Ok, thanks for clarifying. The issue I encountered was that if I ran tools/make_specfiles afterwards (after setting up msvcr120_app to be synced against msvcr120), the make_specfiles script ended up changing msvcr120_app.spec like this:
-@ stub _wperror +@ cdecl _wperror(wstr) msvcr120._wperror
(Which is wrong since _wperror only is a stub in msvcr120 as well.)
But I guess this is an issue with make_specfiles then, not with the specfile itself.
// Martin
Martin Storsjö martin@martin.st writes:
Ok, thanks for clarifying. The issue I encountered was that if I ran tools/make_specfiles afterwards (after setting up msvcr120_app to be synced against msvcr120), the make_specfiles script ended up changing msvcr120_app.spec like this:
-@ stub _wperror +@ cdecl _wperror(wstr) msvcr120._wperror
(Which is wrong since _wperror only is a stub in msvcr120 as well.)
There's nothing wrong with forwarding to a stub.
Martin Storsjö martin@martin.st writes:
Ok, thanks for clarifying. The issue I encountered was that if I ran tools/make_specfiles afterwards (after setting up msvcr120_app to be synced against msvcr120), the make_specfiles script ended up changing msvcr120_app.spec like this:
-@ stub _wperror +@ cdecl _wperror(wstr) msvcr120._wperror
(Which is wrong since _wperror only is a stub in msvcr120 as well.)
There's nothing wrong with forwarding to a stub.
Oh, of course. Then there's no issue at all, and this patch can be dropped.
// Martin
-
Alexandre Julliard -
Martin Storsjö