ruby one-click installer issue with extensions

Discussion in 'Ruby' started by Curt Hibbs, Jun 18, 2004.

  1. Curt Hibbs

    Curt Hibbs Guest

    I'm cross-posting this to see if anyone here can offer more concrete and/or
    accurate advice.

    Jeff Mitchell wrote:
    >
    > I'm hunting down the reason why my package
    > (http://linalg.rubyforge.org) crashes with the ruby shipped in the
    > one-click installer. I am running Windows 2000 with all the latest
    > Windows Updates.
    >
    > I have no problems when I use my own i386-mswin32-ruby-1.8.1 built
    > with VC++ 6.0 SP5 from the standard ruby tarball. The extensions are
    > built with mingw32-gcc-3.3.1.
    >
    > For good measure I attempted to compile the extensions with VC++, but
    > I hit a stream of errors in Winnt.h. (These errors are intractable; I
    > even looked at the raw preprocessor output and found no difference in
    > the problematic section, starting at line 161.)


    This may be precisely what you need to do. I would post your compile errors
    on ruby-talk ML to see if you can get some help.

    > In any case, to my knowledge mingw32 should be fully compatible since
    > it shares the same runtime, libmsvcrt-ruby18. It runs fine on
    > mingw32-ruby as well. (And no problems on the i686-linux side
    > either.)


    I'm no expert here, but my expectation would be the opposite, since mingw32
    compiled code runs through an emulation layer while natively compiled code
    does not.

    Since the Ruby Installer for Windows is compiled natively (with VC++ 7.1),
    and your extension is compiled with mingw32, I would expect problems, and
    perhaps that is the source of the segfaults you mention below.

    I'm going to cross post this to the ruby-talk ML, and the ruby-installer-dev
    ML to get some other opinions on this.

    > Though my package uses LAPACK (a linear algebra library), it is linked
    > statically.
    >
    > I'm a little befuddled. Are there any known issues with extension
    > classes and the one-click installer?
    >
    > I noticed that you included the 7.1 runtime,


    This is because not all windows systems have this runtime installed, and the
    whole point of a one-click installer is that it be "one-click" (that is, the
    user should not have to download and install a missing runtime dll).

    Curt


    ---
    Incoming mail is certified Virus Free.
    Checked by AVG anti-virus system (http://www.grisoft.com).
    Version: 6.0.699 / Virus Database: 456 - Release Date: 6/4/2004
    Curt Hibbs, Jun 18, 2004
    #1
    1. Advertising

  2. Curt Hibbs

    daz Guest

    Curt Hibbs wrote:
    >
    > Since the Ruby Installer for Windows is compiled natively (with VC++ 7.1),
    > and your extension is compiled with mingw32, I would expect problems, and
    > perhaps that is the source of the segfaults [...].
    >
    > I'm going to cross post this to the ruby-talk ML, and the ruby-installer-dev
    > ML to get some other opinions on this.
    >


    Hi Curt,

    *Just* an opinion ...

    I wonder if it's _generally_ possible for users of a one-click installer
    to use the Ruby process to add C extensions locally?

    Part of your build creates config.h, config.status & rbconfig.rb which
    reflect your environment, as you know.
    Data such as compiler options are taken from here as input to mkmf.rb
    but bear little, or no relation to the user's environment.

    To be able to install C extensions easily, my assumption was that a
    self-built Ruby would be a prerequisite unless a user was prepared to do
    some serious reworking of the generated makefiles and, maybe, others.


    daz
    daz, Jun 18, 2004
    #2
    1. Advertising

  3. --- daz <> wrote:
    >
    > Curt Hibbs wrote:
    > >
    > > Since the Ruby Installer for Windows is compiled natively (with VC++ 7.1),
    > > and your extension is compiled with mingw32, I would expect problems, and
    > > perhaps that is the source of the segfaults [...].
    > >
    > > I'm going to cross post this to the ruby-talk ML, and the ruby-installer-dev
    > > ML to get some other opinions on this.
    > >

    >
    > Hi Curt,
    >
    > *Just* an opinion ...
    >
    > I wonder if it's _generally_ possible for users of a one-click installer
    > to use the Ruby process to add C extensions locally?
    >
    > Part of your build creates config.h, config.status & rbconfig.rb which
    > reflect your environment, as you know.
    > Data such as compiler options are taken from here as input to mkmf.rb
    > but bear little, or no relation to the user's environment.
    >
    > To be able to install C extensions easily, my assumption was that a
    > self-built Ruby would be a prerequisite unless a user was prepared to do
    > some serious reworking of the generated makefiles and, maybe, others.


    Do you mean compiling extensions, or installing them? To compile them
    you need a C compiler, of course :) Extensions go into $sitelibdir, which
    translates into /ruby-install-directory/lib/ruby/site_ruby/1.8/i386-msvcrt
    for the one-click installer, so packages know where to install extensions.

    Regarding compiling with mingw32 verses VC++, it's a red herring insofar
    as the one-click installer's current problem, as evidenced by the
    segfault I demonstrated using a simple "hello world" extension compiled
    with VC++ 6.0 SP5.

    Having the same compiler used to build the ruby which you are running
    certainly helps, but it is by no means necessary as long there is a
    standard runtime environment provided, namely msvcrt-ruby18.lib. The
    one-click installer is somehow deviating from that standard, or has
    introduced some other issue in the patch it uses.





    __________________________________
    Do you Yahoo!?
    Read only the mail you want - Yahoo! Mail SpamGuard.
    http://promotions.yahoo.com/new_mail
    Jeff Mitchell, Jun 18, 2004
    #3
  4. --- Jeff Mitchell <> wrote:
    > Extensions go into $sitelibdir, which

    ^^^^^^^^^^^
    Just to be pedantic, this should be $sitearchdir

    > translates into /ruby-install-directory/lib/ruby/site_ruby/1.8/i386-msvcrt


    this is right.




    __________________________________
    Do you Yahoo!?
    Yahoo! Mail is new and improved - Check it out!
    http://promotions.yahoo.com/new_mail
    Jeff Mitchell, Jun 18, 2004
    #4
  5. Curt Hibbs

    daz Guest

    Jeff Mitchell wrote:
    > --- daz wrote:
    > >
    > > [config.h, config.status & rbconfig.rb]
    > > Data such as compiler options are taken from here as input to mkmf.rb
    > > but bear little, or no relation to the user's environment.
    > >
    > > To be able to install C extensions easily, my assumption was that a
    > > self-built Ruby would be a prerequisite unless a user was prepared to do
    > > some serious reworking of the generated makefiles and, maybe, others.

    >
    > Do you mean compiling extensions, or installing them? To compile them
    > you need a C compiler, of course :)


    Given those two alternatives, I'd say both.

    > Extensions go into [$sitearchdir], which translates into
    > /ruby-install-directory/lib/ruby/site_ruby/1.8/i386-msvcrt for the
    > one-click installer, so packages know where to install extensions.
    >


    Indeed, and when I was using one-click from Prag/\ndy, I noticed that
    a lot of these directories were set to drive T:\ . Not difficult to
    find and change those, but wherever you #include "ruby.h", some
    subtle upset might occur from using a config.h file which contains
    #defines tailored to someone else's machine.

    It might not be a problem, but I'm not inclined towards finding out.


    daz
    daz, Jun 19, 2004
    #5
  6. "daz" <> wrote in message news:<>...
    > > Extensions go into [$sitearchdir], which translates into
    > > /ruby-install-directory/lib/ruby/site_ruby/1.8/i386-msvcrt for the
    > > one-click installer, so packages know where to install extensions.
    > >

    >
    > Indeed, and when I was using one-click from Prag/\ndy, I noticed that
    > a lot of these directories were set to drive T:\ . Not difficult to
    > find and change those, but wherever you #include "ruby.h", some
    > subtle upset might occur from using a config.h file which contains
    > #defines tailored to someone else's machine.
    >
    > It might not be a problem, but I'm not inclined towards finding out.


    It isn't :)

    If you look at rbconfig.rb, you'll find the paths are all defined
    relative to

    TOPDIR = File.dirname(__FILE__).sub!(%r'/lib/ruby/1\.8/i386\-mswin32\Z', '')

    If you had to change paths from "T:\" in rbconfig.rb then it was a bug
    which has since been resolved.

    The one-click installer's config.h has the following paths

    #define RUBY_LIB "/lib/ruby/1.8"
    #define RUBY_SITE_LIB "/lib/ruby/site_ruby"
    #define RUBY_SITE_LIB2 "/lib/ruby/site_ruby/1.8"
    #define RUBY_PLATFORM "i386-mswin32"
    #define RUBY_ARCHLIB "/lib/ruby/1.8/i386-mswin32"
    #define RUBY_SITE_ARCHLIB "/lib/ruby/site_ruby/1.8/i386-msvcrt"

    all of which have the $prefix removed. The same is true for
    mingw32-ruby's config.h. If you saw "T:\" here then it has since been
    removed.

    On Linux, however, the $prefix is present. In any case, I cannot
    imagine a valid use of these raw paths except as convenience to C
    extension writers who do not intend to distribute their work. A
    programmer would know they are locally dependent simply because they
    are #defines.

    So to answer your original question, "I wonder if it's _generally_
    possible for users of a one-click installer to use the Ruby process to
    add C extensions locally?" the answer is yes -- that's what an
    install.rb does: it reads rbconfig.rb and then knows where to install.
    The other things in config.h like sizeof(double) are fixed because of
    the Win32 specification.
    Jeff Mitchell, Jun 19, 2004
    #6
  7. Curt Hibbs

    daz Guest

    Jeff Mitchell wrote:
    >
    > "daz" wrote:
    > >
    > > Indeed, and when I was using one-click from Prag/\ndy, I noticed that
    > > a lot of these directories were set to drive T:\ . Not difficult to
    > > find and change those, but wherever you #include "ruby.h", some
    > > subtle upset might occur from using a config.h file which contains
    > > #defines tailored to someone else's machine.
    > >
    > > It might not be a problem, but I'm not inclined towards finding out.

    >
    > It isn't :)
    >
    > <snip reasoned explanation ...>
    >


    Thanks, Jeff.

    I'm glad that's not an obstacle for one-click users who want to compile.


    daz
    daz, Jun 19, 2004
    #7
    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. Curt Hibbs
    Replies:
    6
    Views:
    129
    Curt Hibbs
    Aug 17, 2004
  2. Curt Hibbs
    Replies:
    20
    Views:
    322
    Lothar Scholz
    Aug 20, 2004
  3. Curt Hibbs
    Replies:
    0
    Views:
    163
    Curt Hibbs
    Aug 18, 2004
  4. Dany Cayouette

    Ruby One-click Installer and ruby 18.4.

    Dany Cayouette, Jan 3, 2006, in forum: Ruby
    Replies:
    7
    Views:
    129
    Austin Ziegler
    Jan 19, 2006
  5. Harold Hausman
    Replies:
    3
    Views:
    177
    Jano Svitok
    Apr 27, 2007
Loading...

Share This Page