| Message ID | 20190718120413.27678-1-marcandre.lureau@redhat.com |
|---|---|
| State | New |
| Headers | show |
| Series | build-sys: do no support modules on Windows | expand |
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
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 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
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
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(-)