[Qemu-devel] [PATCH] build-sys: do no support modules on Windows

[Qemu-devel] [PATCH] build-sys: do no support modules on Windows

[Marc-André Lureau]

Our module system does not support Windows, because it relies on
resolving symbols from the main executable.

If there is enough interest in supporting modules on Windows, we could
generate an import library for the executable and link with it:
https://stackoverflow.com/questions/15454968/dll-plugin-that-uses-functions-defined-in-the-main-executable

However, there is a small chicken egg problem, since the executable
link and exports extra symbols needed by the library...

Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
---
 configure | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/configure b/configure
index eb635c3b9a..2833402844 100755
--- a/configure
+++ b/configure
@@ -1751,7 +1751,7 @@ disabled with --disable-FEATURE, default is enabled if available:
   guest-agent     build the QEMU Guest Agent
   guest-agent-msi build guest agent Windows MSI installation package
   pie             Position Independent Executables
-  modules         modules support
+  modules         modules support (non-Windows)
   debug-tcg       TCG debugging (default is disabled)
   debug-info      debugging information
   sparse          sparse checker
@@ -2006,6 +2006,11 @@ else
   QEMU_CFLAGS="$QEMU_CFLAGS -Wno-missing-braces"
 fi
 
+# Our module code doesn't support Windows
+if test "$modules" = "yes" && test "$mingw32" = "yes" ; then
+  error_exit "Modules are not available for Windows"
+fi
+
 # Static linking is not possible with modules or PIE
 if test "$static" = "yes" ; then
   if test "$modules" = "yes" ; then
-- 
2.22.0.428.g6d5b264208

Re: [Qemu-devel] [PATCH] build-sys: do no support modules on Windows

[Daniel P. Berrangé]

On Thu, Jul 18, 2019 at 04:04:13PM +0400, Marc-André Lureau wrote:
> Our module system does not support Windows, because it relies on
> resolving symbols from the main executable.
> 
> If there is enough interest in supporting modules on Windows, we could
> generate an import library for the executable and link with it:
> https://stackoverflow.com/questions/15454968/dll-plugin-that-uses-functions-defined-in-the-main-executable
> 
> However, there is a small chicken egg problem, since the executable
> link and exports extra symbols needed by the library...

The "solution" to that would presumably be to put everything into a
library, and the executable merely becomes trivial main() that calls
a "runme" function in the library. It is kind of ugly though as we
would need a separate library for each system emulator executable.

Just ignoring modules on Windows looks like the prudent solution.

> 
> Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
> ---
>  configure | 7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)

Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: [Qemu-devel] [PATCH] build-sys: do no support modules on Windows

[Paolo Bonzini]

On 18/07/19 14:04, Marc-André Lureau wrote:
> Our module system does not support Windows, because it relies on
> resolving symbols from the main executable.
> 
> If there is enough interest in supporting modules on Windows, we could
> generate an import library for the executable and link with it:
> https://stackoverflow.com/questions/15454968/dll-plugin-that-uses-functions-defined-in-the-main-executable
> 
> However, there is a small chicken egg problem, since the executable
> link and exports extra symbols needed by the library...

Yeah, with Meson it would be possible to do this easily, but for now
let's just drop support for modules on Windows.

Paolo

Re: [Qemu-devel] [PATCH] build-sys: do no support modules on Windows

[Paolo Bonzini]

On 18/07/19 14:49, Daniel P. Berrangé wrote:
> On Thu, Jul 18, 2019 at 04:04:13PM +0400, Marc-André Lureau wrote:
>> Our module system does not support Windows, because it relies on
>> resolving symbols from the main executable.
>>
>> If there is enough interest in supporting modules on Windows, we could
>> generate an import library for the executable and link with it:
>> https://stackoverflow.com/questions/15454968/dll-plugin-that-uses-functions-defined-in-the-main-executable
>>
>> However, there is a small chicken egg problem, since the executable
>> link and exports extra symbols needed by the library...
> 
> The "solution" to that would presumably be to put everything into a
> library, and the executable merely becomes trivial main() that calls
> a "runme" function in the library. It is kind of ugly though as we
> would need a separate library for each system emulator executable.
> 
> Just ignoring modules on Windows looks like the prudent solution.

See https://github.com/mesonbuild/meson/pull/3683#issuecomment-467815241

The trick is to build the modules in two phases, first as a static
library and then as a shared module (with Meson you'd use link_whole).
Then the list of symbols can be gleaned from the static libraries, but
the executable can still be linked before the shared module:

modules_objs = {}
modules_objs += { 'b': static_library('b.mo', 'src.c', pic: true) }
# ...

undef = []
undefdeps = []
foreach name, lib : modules_objs
    shared_module(name, link_whole: lib, link_with: e)
    undefdeps += [custom_target('undefsym', output: [name+'.undef'],
                            input: lib,
                            command: [files('undefsym.sh'),
                                      '@OUTPUT0@', '@INPUT@'])]
    undef += [ '@' + name + '.undef' ]
endforeach

libutil = static_library('util', 'util.c', pic: true)
e = executable('a', 'main.c', link_with: [libutil],
               link_args: undef, link_depends: undefdeps,
               implib: true)

This in fact is exactly what we're doing now, just with a .o file and
"ld -r" instead of a .a file that is wholly-linked into the shared module.

Paolo