«

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