Feature #16795
open
build ruby.exe on Windows against ruby-static.lib omitting x64-vcruntime-ruby.dll (no '--enable-shared' option for Windows)
Description
I'm trying to build ruby for embedded windows environment. It would help a lot if I would be able to do it without '--enable-shared'
as it could be done for Linux platform. So on linux just ruby-static.a built, without any .so.
Executable is about 10Mb and it depends only on libc, libm, libdl, libphtread.
But in windows case there is no such option in configure.bat and as a result I have
18Kb executable and 3Mb x64-vcruntime-ruby.dll. Even if I hack Makefile.sub and change 'enable_shared' from 'yes' to 'no' it
just doesn't build .dll but executable is still 18Kb and relies on missed dll, it doesn't get linked against libruby-static.lib.
The real problem I have later when I try to build some C native extensions, so byebug for example generates its makefile
automatically and builds also against x64-vcruntime-ruby.dll which leads to some segfaults because it just calls functions
from .dll which is present on host but not in embedded environment. In case of linux nmap just shows that during byebug
linking all ruby functions like st_lookup etc are undefined ('U' symbol). So it finds this functions later.
But on Windows when I build byebug it already depends on x64-vcruntime-ruby.dll
Is there any way to build ruby.exe on Windows against static lib, without relying on .dll ?
So it seems '--enable-shared' on Windows is just enabled by default and there is no correct way to disable it (but could be done on Linux platform)
Updated by shevegen (Robert A. Heiler) over 4 years ago
I feel you here. Not so much due to windows, but I totally understand every
preference for --enable-shared and --enable static. :-)
Perhaps nobu and greg can help for the windows-related issues; perhaps greg
even through some automated testing of required build options for your
described goal ("ruby for an embedded windows environment").
May also be that not many people test the windows-build options, I think, as
there may be fewer ruby devs on windows (but I do not know this for
certain, I just assume). But I completely understand it - I want a super-easy,
super-modular ruby too, with lots of flexibility for usage/deployment. And
to work on every operating system too. :-)
Updated by repu1sion (Andrii Guriev) over 4 years ago
shevegen (Robert A. Heiler) wrote in #note-1:
I feel you here. Not so much due to windows, but I totally understand every
preference for --enable-shared and --enable static. :-)Perhaps nobu and greg can help for the windows-related issues; perhaps greg
even through some automated testing of required build options for your
described goal ("ruby for an embedded windows environment").May also be that not many people test the windows-build options, I think, as
there may be fewer ruby devs on windows (but I do not know this for
certain, I just assume). But I completely understand it - I want a super-easy,
super-modular ruby too, with lots of flexibility for usage/deployment. And
to work on every operating system too. :-)
just simple instructions how to build ruby.exe against static library instead of linking with x64-vcruntime-ruby.dll would be enough ;)