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

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Jannick
Hi,

This is a pure Windows issue:

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.

Happy to draft a patch for this, if you guys would be OK with the proposed
idea.


Many thanks,
J.



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
> From: "Jannick" <[hidden email]>
> 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?
In particular, can you show how the hard-coded name of the executable
prevents linking against the import library?

Thanks.

Reply | Threaded
Open this post in threaded view
|

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" <[hidden email]>
> > 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.


Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
> From: "Jannick" <[hidden email]>
> Cc: <[hidden email]>
> Date: Sun, 3 Nov 2019 22:01:06 +0100
>
> > 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.

And how do you suggest to fix this?

Reply | Threaded
Open this post in threaded view
|

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

Jannick
On Mon, 04 Nov 2019 05:35:46 +0200, Eli Zaretskii wrote:

> And how do you suggest to fix this?

For your consideration attached 3 patches implementing the suggested idea: a
new optional command line flag '--exe-name' to build_w32.bat to help the
user pass an executable name (default: 'gnumake') used at link time.

Please feel free to edit and apply it.

Thanks,
J.

0001-Windows-build-regroup-code-blocks-in-build_w32.bat.patch (1K) Download Attachment
0002-Windows-build-enhance-error-reporting-in-build_w32.b.patch (1K) Download Attachment
0003-Windows-build-add-optional-cmd-line-flag-exe-name-to.patch (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
> From: "Jannick" <[hidden email]>
> Cc: <[hidden email]>
> Date: Thu, 7 Nov 2019 12:32:23 +0100
>
> Subject: [PATCH 03/13] Windows build: add optional cmd line flag --exe-name to
>  build_w32.bat
>
> This commit helps the user choose a name for the GNUMake executable
> different from the default 'gnumake.exe' used at link time.

This patches only the GCC part of the script.  Does that mean the MSVC
part already caters to your use case in some way?

Paul, I think we have a situation here, most probably my fault.
Currently, we produce the executable named gnumake.exe, but we install
it as something else, like make.exe, which means the importy library
will not work, because the name gnumake.exe is hard-coded in the
import library when we build it.  I think I failed to consider this
aspect when I implemented the Windows support of shared object
loading.

Does the same problem exist with the MSVC builds?  If not, how this
issue is resolved in that case?

One solution of this would be to also build a DEF file, and tell users
to edit the name of the executable in that file and then create an
import library from the DEF file using dlltool, if they rename the
executable.

Another solution is the 3rd patch sent by Jannick, but I like his
solution less because it doesn't allow to rename the executable after
it is built.

WDYT?

Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
Ping!  Paul, did you have a chance to look at this issue?

> Date: Thu, 07 Nov 2019 17:29:48 +0200
> From: Eli Zaretskii <[hidden email]>
> Cc: [hidden email]
>
> > From: "Jannick" <[hidden email]>
> > Cc: <[hidden email]>
> > Date: Thu, 7 Nov 2019 12:32:23 +0100
> >
> > Subject: [PATCH 03/13] Windows build: add optional cmd line flag --exe-name to
> >  build_w32.bat
> >
> > This commit helps the user choose a name for the GNUMake executable
> > different from the default 'gnumake.exe' used at link time.
>
> This patches only the GCC part of the script.  Does that mean the MSVC
> part already caters to your use case in some way?
>
> Paul, I think we have a situation here, most probably my fault.
> Currently, we produce the executable named gnumake.exe, but we install
> it as something else, like make.exe, which means the importy library
> will not work, because the name gnumake.exe is hard-coded in the
> import library when we build it.  I think I failed to consider this
> aspect when I implemented the Windows support of shared object
> loading.
>
> Does the same problem exist with the MSVC builds?  If not, how this
> issue is resolved in that case?
>
> One solution of this would be to also build a DEF file, and tell users
> to edit the name of the executable in that file and then create an
> import library from the DEF file using dlltool, if they rename the
> executable.
>
> Another solution is the 3rd patch sent by Jannick, but I like his
> solution less because it doesn't allow to rename the executable after
> it is built.
>
> WDYT?
>
>

Reply | Threaded
Open this post in threaded view
|

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

Paul Smith-20
On Fri, 2019-11-15 at 15:52 +0200, Eli Zaretskii wrote:
> Ping!  Paul, did you have a chance to look at this issue?

Sorry, I'm quite underwater.  I hope to be able to do a bit of make work
over the next few weeks: get out a final RC and a release.

For this, I don't really understand the issue :).  What is the import
library used for?  Make is an executable, right?  Are we talking about
creating loadable objects here?

I have no preferences for filenames whatsoever: I used whatever was there
before.  I admit I find it a bit annoying that the .bat file creates a
differently-named executable in a subdirectory, because I always forget and
have to re-remember it when running tests, but I leave these decisions up
to the folks who actually use Windows.

The extent of my usage is just making sure that it compiles and runs on
Windows with MSVC since that's what I have access to.

So upshot is: whatever you guys feel is right is just fine with me :).


> > Date: Thu, 07 Nov 2019 17:29:48 +0200
> > From: Eli Zaretskii <[hidden email]>
> > Cc: [hidden email]
> >
> > > From: "Jannick" <[hidden email]>
> > > Cc: <[hidden email]>
> > > Date: Thu, 7 Nov 2019 12:32:23 +0100
> > >
> > > Subject: [PATCH 03/13] Windows build: add optional cmd line flag --
> > > exe-name to build_w32.bat
> > >
> > > This commit helps the user choose a name for the GNUMake executable
> > > different from the default 'gnumake.exe' used at link time.
> >
> > This patches only the GCC part of the script.  Does that mean the MSVC
> > part already caters to your use case in some way?
> >
> > Paul, I think we have a situation here, most probably my fault.
> > Currently, we produce the executable named gnumake.exe, but we install
> > it as something else, like make.exe, which means the importy library
> > will not work, because the name gnumake.exe is hard-coded in the
> > import library when we build it.  I think I failed to consider this
> > aspect when I implemented the Windows support of shared object
> > loading.
> >
> > Does the same problem exist with the MSVC builds?  If not, how this
> > issue is resolved in that case?
> >
> > One solution of this would be to also build a DEF file, and tell users
> > to edit the name of the executable in that file and then create an
> > import library from the DEF file using dlltool, if they rename the
> > executable.
> >
> > Another solution is the 3rd patch sent by Jannick, but I like his
> > solution less because it doesn't allow to rename the executable after
> > it is built.
> >
> > WDYT?


Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
> From: Paul Smith <[hidden email]>
> Cc: [hidden email], [hidden email]
> Date: Tue, 19 Nov 2019 09:22:17 -0500
>
> On Fri, 2019-11-15 at 15:52 +0200, Eli Zaretskii wrote:
> > Ping!  Paul, did you have a chance to look at this issue?
>
> Sorry, I'm quite underwater.  I hope to be able to do a bit of make work
> over the next few weeks: get out a final RC and a release.

OK.

> For this, I don't really understand the issue :).  What is the import
> library used for?

It is used to build loadable objects.  Since they call functions that
are implemented inside the Make executable, on Windows you must link
them against the import library that tells where to find the
implementation at run time.

> Make is an executable, right?

Yes.

> Are we talking about creating loadable objects here?

Yes.  But, while normally an import library is used for DLLs, here we
have the reverse situation: a DLL that needs to call a function inside
the Make executable.

> I have no preferences for filenames whatsoever: I used whatever was there
> before.

It isn't about choosing a file name.  This is about the fact that the
name of the executable whose link command produced an import library
is hard-coded into the import library, so that a loadable object
linked against that import library will look for the Make executable
by that name when it tries to invoke one of the API functions.  And we
produce an executable called gnumake.exe, so that's what the loadable
objects will look for -- and will fail, because Make is installed
under a different file name, typically make.exe or mingw32-make.exe.

> The extent of my usage is just making sure that it compiles and runs on
> Windows with MSVC since that's what I have access to.

Did you try to run the tests from the test suite that load shared
objects or verify the API, with the MSVC-compiled Make?  I think they
will all fail if Make's executable file is not called gnumake.exe.

My question was how to allow end-users rename the Make executable,
without breaking the loadable objects.  I proposed several
alternatives.  There's one more, btw: the end-user could link against
make.exe (or whatever it's called) directly, bypassing the import
library.

I'd really like to hear your views and opinions on this issue.  If
this will have to wait until you have more time to think about the
issue, so be it.

Thanks.