miniruby.exe & statically linked ruby.exe (Windows)

[Phil Tomson]

I've been trying to build a statically linked ruby.exe on windows using
MSVC. I think I might have been successful, but I'm ending up with a
filee that is exactly the same size as the miniruby.exe that gets created
by win32/Makefile.sub.

I'm assuming (because of the name) that miniruby.exe is missing something.
Is this true, and if so, what's missing? [Actually, I just tried to run
my script with miniruby.exe and found that it couldn't require net/http.
Same goes for the statically linked ruby.exe I created, so it's apparently
equivilent to miniruby.exe]

Can anyone give me any clues about building a statically linked ruby.exe
on Windows using the microsoft compiler?

Phil

 

[daz]

I've been trying to build a statically linked ruby.exe on windows using
MSVC. I think I might have been successful, ...

I think so, too.

I'm assuming (because of the name) that miniruby.exe is missing something.
Is this true, and if so, what's missing?

I'm going by the bcc build but, having glanced at the ms makefiles, there
doesn't seem to be any difference. With that caveat; it's only missing
the resource file (.res) which might be better added in. That'll make
version information available on the "Properties" sheet and to any other
utilities that look for it.

So, looking at these two sections ...

miniruby$(EXEEXT):
@echo. $(LIBS)
$(PURIFY) $(CC) $(MAINOBJ) $(LIBRUBY_A) $(LIBS) -Fe$@ $(LDFLAGS)

$(PROGRAM): $(RUBY_INSTALL_NAME).res
$(PURIFY) $(CC) $(MAINOBJ) $(RUBY_INSTALL_NAME).res \
$(OUTFLAG)$@ $(LIBRUBYARG) $(LDFLAGS) $(XLDFLAGS)

.... to give miniruby (or your version) a resource, change:

$(PURIFY) $(CC) $(MAINOBJ) $(LIBRUBY_A) $(LIBS) -Fe$@ $(LDFLAGS)
to:
$(PURIFY) $(CC) $(MAINOBJ) $(LIBRUBY_A) $(LIBS) $(RUBY_INSTALL_NAME).res -Fe$@ $(LDFLAGS)

(It appears that MSVC will accept the .res file almost anywhere on the compile line ??)

[Actually, I just tried to run my script with miniruby.exe and found that
it couldn't require net/http. Same goes for the statically linked ruby.exe
I created, so it's apparently equivilent to miniruby.exe]

It is.

Ruby.exe & miniruby.exe build their loadpaths relative to the directory
they are in (can be overridden with environment variables). I copied
miniruby to an empty dir and ran this from the Start/Run box:

C:\tmp\miniruby.exe -e"puts $:; gets"

resulting in:

C:/TMP/lib/ruby/site_ruby/1.9
C:/TMP/lib/ruby/site_ruby/1.9/i586-bccwin32
C:/TMP/lib/ruby/site_ruby
C:/TMP/lib/ruby/1.9
C:/TMP/lib/ruby/1.9/i586-bccwin32
..

Any files your users want to require will need to be in that relative
directory structure. As you know, '.' represents the current directory.

If you want to bundle statically linked extensions, I think you just
uncomment the corresponding line in ext\Setup before building.

Can anyone give me any clues about building a statically linked ruby.exe
on Windows using the microsoft compiler?

No, sorry; ask Phil T.


daz

 

[Phil Tomson]

I've been trying to build a statically linked ruby.exe on windows using
MSVC. I think I might have been successful, ...

I think so, too.

I'm assuming (because of the name) that miniruby.exe is missing something.
Is this true, and if so, what's missing?

I'm going by the bcc build but, having glanced at the ms makefiles, there
doesn't seem to be any difference. With that caveat; it's only missing
the resource file (.res) which might be better added in. That'll make
version information available on the "Properties" sheet and to any other
utilities that look for it.

So, looking at these two sections ...

miniruby$(EXEEXT):
@echo. $(LIBS)
$(PURIFY) $(CC) $(MAINOBJ) $(LIBRUBY_A) $(LIBS) -Fe$@ $(LDFLAGS)

$(PROGRAM): $(RUBY_INSTALL_NAME).res
$(PURIFY) $(CC) $(MAINOBJ) $(RUBY_INSTALL_NAME).res \
$(OUTFLAG)$@ $(LIBRUBYARG) $(LDFLAGS) $(XLDFLAGS)

... to give miniruby (or your version) a resource, change:

$(PURIFY) $(CC) $(MAINOBJ) $(LIBRUBY_A) $(LIBS) -Fe$@ $(LDFLAGS)
to:
$(PURIFY) $(CC) $(MAINOBJ) $(LIBRUBY_A) $(LIBS)
$(RUBY_INSTALL_NAME).res -Fe$@ $(LDFLAGS)

(It appears that MSVC will accept the .res file almost anywhere on the
compile line ??)

[Actually, I just tried to run my script with miniruby.exe and found that
it couldn't require net/http. Same goes for the statically linked ruby.exe
I created, so it's apparently equivilent to miniruby.exe]

It is.

Ruby.exe & miniruby.exe build their loadpaths relative to the directory
they are in (can be overridden with environment variables). I copied
miniruby to an empty dir and ran this from the Start/Run box:

C:\tmp\miniruby.exe -e"puts $:; gets"

resulting in:

C:/TMP/lib/ruby/site_ruby/1.9
C:/TMP/lib/ruby/site_ruby/1.9/i586-bccwin32
C:/TMP/lib/ruby/site_ruby
C:/TMP/lib/ruby/1.9
C:/TMP/lib/ruby/1.9/i586-bccwin32
.

Ah... that's what's going on.

Any files your users want to require will need to be in that relative
directory structure. As you know, '.' represents the current directory.

If you want to bundle statically linked extensions, I think you just
uncomment the corresponding line in ext\Setup before building.

That's true on Linux, I suppose it probably also works that way for the
Windows build as well.

No, sorry; ask Phil T.

Good to know that I got it to work.

Why is it that the makefile creates both miniruby.exe(statically linked)
and ruby.exe (dynamically linked) that are essentially equivilent?

Phil

 

[daz]

That's true on Linux, I suppose it probably also works that way for the
Windows build as well.

Haven't tried, but two of the entries are Win32API & win32ole,
so I thought I was on safe ground there.

Why is it that the makefile creates both miniruby.exe(statically linked)
and ruby.exe (dynamically linked) that are essentially equivilent?

Phil

I assume it's to prevent the risk of crashes during the build process
which uses Ruby scripts to build itself.
Imagine what could happen if it were to use ruby.exe (which is calling
functions in the dll) while a new dll is being built. I should think
Windows would barff, at least.
With miniruby.exe, there's a self-contained ruby available with which
to run build scripts. It may or may not be the same version as the one
that's being built but that shouldn't matter.


daz

 

[Phil Tomson]

I think so, too.

Actually, now I don't think so...

As you'll recall, I ended up with miniruby.exe and ruby.exe being the same
size. We figured that they were equivilent (which they seem to be),
however, the missing part of miniruby.exe is that it can't load shared
libs (Win32API.so in this case) and neither can the ruby.exe built this
way.... back to the drawing board.

Phil

 

[daz]

Actually, now I don't think so...

As you'll recall, I ended up with miniruby.exe and ruby.exe being the same
size. We figured that they were equivilent (which they seem to be),
however, the missing part of miniruby.exe is that it can't load shared
libs (Win32API.so in this case) and neither can the ruby.exe built this
way.... back to the drawing board.

Phil

Well that'll be because Win32API.so is still dynamically linked to the
ruby dll which is not in your new path.

Time to try the ext\Setup method of static linking libraries?


daz

 

[daz]

Well that'll be because Win32API.so is still dynamically linked to the
ruby dll which is not in your new path.

That should have been fixed by temporarily copying the dll into the same
folder as Win32API.so, but it wasn't :/

Haven't time to fiddle, but I'd be interested if you come up with anything.


daz

 

[Phil Tomson]

Well that'll be because Win32API.so is still dynamically linked to the
ruby dll which is not in your new path.

Well, there's a Win32API.so in ext/Win32API and I explicitly specified the
whole path to it and got a crash (illegal instruction or somesuch) so I'm
sure I got the right .so file.

Time to try the ext\Setup method of static linking libraries?

Maybe, it seems I tried it though, and didn't see the binary get any
larger which is what I would have expected. On Linux I believe you have
to edit ext/Setup and then re-run configure, but the Windows configure.bat
doesn't seem to do much...

Phil

 

[daz]

Well, there's a Win32API.so in ext/Win32API and I explicitly specified the
whole path to it and got a crash (illegal instruction or somesuch) so I'm
sure I got the right .so file.


Maybe, it seems I tried it though, and didn't see the binary get any
larger which is what I would have expected. On Linux I believe you have
to edit ext/Setup and then re-run configure, but the Windows configure.bat
doesn't seem to do much...

Phil

On Windows, the magic seems to occur in ext\extmk.rb which tries to create
and run makefiles for each of the extensions in the ext directory.
It looks at ext\Setup for any "static" requests and proceeds as follows
for any that it finds:

1) creates a .lib file for eventual merger into xxx-ruby18-static.lib
2) adds its name to a generated "C" file called extinit.c which would
be called by ruby.exe to "automatically require" static exts.

This is what would be done manually but most cleverly automated, IMO.

Yes, you could have a static ruby.exe (900+Kb) and a static
Win32API (900+Kb) etc., but really you only want the functions from
xxx-ruby18-static.lib included once in the final .exe and that's what
the build process attempts to do.

I'm not seriously determined to get this to work, so I haven't checked
my procedures carefully but, ATM, I have a statically linked Ruby +
Win32API + stringio + socket (Total size 900+Kb) which fails to
"auto-require". Grepping ruby.c for "Init_ext()" and "require_libraries()"
finds comments which suggest that this area may be not quite complete.
I'd estimate that it's not far off target, though.


daz

 

[Phil Tomson]

I'm not seriously determined to get this to work, so I haven't checked
my procedures carefully but, ATM, I have a statically linked Ruby +

WHOA! Hold on there... How did you get a statically linked Ruby? That's
what I'm trying to get working. I really don't care if I still have to
require a seperate Win32API.so - that's no big deal. But I don't want to
have to ship that msvcrt-ruby18.dll with my application. I can ship a
Win32API.so, that's no problem... yes it sounds complicated and it is
because these are Lawyers we're dealing with and since the regex library
is under LGPL I can't have a dynamically linked ruby.exe. To put it
succinctly: the Lawyers won't be happy with having to ship a
msvcrt-ruby18.dll on our CD (actually, 'happy' isn't the right way to put
it, they won't allow it is probably more accurate). A statically linked
ruby.exe is what I need, how'd you do it?

Phil

 

[daz]

WHOA! Hold on there... How did you get a statically linked Ruby?

Gone to e-mail. [Edited reply: Same way you did ?]

One of us should remember to post a summary of any conclusion.


daz

 

[Dick Davies]

WHOA! Hold on there... How did you get a statically linked Ruby?

Gone to e-mail. [Edited reply: Same way you did ?]

One of us should remember to post a summary of any conclusion.

Might be worth sticking it on the Wiki?