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
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
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 :|
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
© 2016 - 2024 Red Hat, Inc.