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

Discussion in 'Ruby' started by Phil Tomson, May 6, 2004.

  1. Phil Tomson

    Phil Tomson Guest

    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
     
    Phil Tomson, May 6, 2004
    #1
    1. Advertising

  2. Phil Tomson

    daz Guest

    Phil Tomson wrote:

    > 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
     
    daz, May 6, 2004
    #2
    1. Advertising

  3. Phil Tomson

    Phil Tomson Guest

    In article <>,
    daz <> wrote:
    >
    >Phil Tomson wrote:
    >
    >> 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.

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

    >
    >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
     
    Phil Tomson, May 6, 2004
    #3
  4. Phil Tomson

    daz Guest

    Phil Tomson wrote:

    > >
    > >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.
    >


    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
     
    daz, May 7, 2004
    #4
  5. Phil Tomson

    Phil Tomson Guest

    In article <>,
    daz <> wrote:
    >
    >Phil Tomson wrote:
    >
    >> 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.


    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
     
    Phil Tomson, May 7, 2004
    #5
  6. Phil Tomson

    daz Guest

    Phil Tomson wrote:
    > daz wrote:
    > >
    > >Phil Tomson wrote:
    > >
    > >> 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.

    >
    > 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, May 7, 2004
    #6
  7. Phil Tomson

    daz Guest

    I wrote:
    >
    > 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
     
    daz, May 7, 2004
    #7
  8. Phil Tomson

    Phil Tomson Guest

    In article <>,
    daz <> wrote:
    >
    >Phil Tomson wrote:
    >> daz wrote:
    >> >
    >> >Phil Tomson wrote:
    >> >
    >> >> 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.

    >>
    >> 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.
    >


    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
     
    Phil Tomson, May 7, 2004
    #8
  9. Phil Tomson

    daz Guest

    Phil Tomson wrote:
    >
    > 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


    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
     
    daz, May 7, 2004
    #9
  10. Phil Tomson

    Phil Tomson Guest

    In article <>,
    daz <> wrote:
    >
    >
    >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
     
    Phil Tomson, May 7, 2004
    #10
  11. Phil Tomson

    daz Guest

    Phil Tomson wrote:
    >
    > 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
     
    daz, May 8, 2004
    #11
  12. Phil Tomson

    Dick Davies Guest

    * daz <> [0514 01:14]:
    >
    > Phil Tomson wrote:
    > >
    > > 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?
    --
    Never commit yourself! Let someone else commit you.
    Rasputin :: Jack of All Trades - Master of Nuns
     
    Dick Davies, May 8, 2004
    #12
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. pratap
    Replies:
    20
    Views:
    787
    Flash Gordon
    Mar 7, 2007
  2. Phil Tomson
    Replies:
    0
    Views:
    130
    Phil Tomson
    May 10, 2004
  3. Replies:
    1
    Views:
    152
  4. Yusuf Celik
    Replies:
    1
    Views:
    150
    Rick DeNatale
    Jul 20, 2007
  5. Edgardo Hames
    Replies:
    0
    Views:
    135
    Edgardo Hames
    Jan 5, 2009
Loading...

Share This Page