RE: [build_w32.bat] feature request: add optional command line argument for executable name

[Jannick]

Hi Eli,

Many thanks for looking into this!

On Sun, 03 Nov 2019 17:35:42 +0200, Eli Zaretskii wrote:
> > From: "Jannick" <address@hidden>
> > Date: Sun, 3 Nov 2019 13:30:11 +0100
> >
> > Would it be possible to pass to build_w32.bat in an optional command
> > line argument the executable name (currently hard coded in the
> > variable MAKE as 'gnumake')?
> >
> > When creating a plugin (.dll) with GCC (by linking against
> > gnumake.dll.a) which should then be called by a version of gnumake.exe
> > with a name other than gnumake.exe, it is not sufficient to simply
> > rename the executable, since that is hard-coded in the .dll.a library.
> > The suggested feature would make things easily happen in this case
> > without using workarounds using .def files, dlltool and alike or even
> patching the .bat file.
>
> I'm not sure I understand the problem, so could you please elaborate?

Sure:  If a plugin (dll) is linked against the import library gnumake.dll.a
as produced by the current version of build_w32.bat, then this plugin works
with gnumake.exe (created by build_w32.bat, too), but not with a copy of
this executable with another name:  To see this let's create a copy of
gnumake.exe named, say, gmake.exe. While gmake.exe is able to load the
plugin, the plugin itself cannot resolve the symbols to be provided by
gmake.exe, although it does have those symbols.  This is what I meant by
saying that the calling exe's name is hard-coded in the import library.

If we want to create a plugin working with the renamed version gmake.exe, I
can see two options: (1) Creating a new import library using an adjusted
import library (applying dlltool) or (2) having build_w32.bat generate
gmake.exe together with the related import library libgmake.dll.a.   The
suggested command line option would cover the latter option which would be
the more simply one I think.

> In particular, can you show how the hard-coded name of the executable
> prevents linking against the import library?

As said above, the issue is not about linking the dll (which should always
work), but that the plugin cannot resolve the symbols expected to be
provided by the executable calling the plugin.

> Thanks.

I hope this clarifies.

Regards,
J.