Forum: Ruby windows gurus i beseech you

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
unknown (Guest)
on 2006-04-08 20:36
(Received via mailing list)
so i need to compile a bunch of stuff on windows.  some third party
stuff and
ruby extensions to those third party libs.  everything i do __must__ be
compatible with the one-click installer, here's what i'm thinking might
be a
good approach:

   assumption : i've read that the latest one-click installer is
compatible with
   mingw output

   assumption : all extensions and libs in question compile under mingw


   step one : configure a ruby from the __same__ sources used for
one-click
   installer using something like

     ./configure --with-gcc='gcc -mno-cygwin' --enable-shared
--prefix='c:\ruby'

   step two : build

     make

   step three : do not install!

   step four : clobber the one-click installer's rbconfig.rb with the
one just
   created!  the idea here is that this rbconfig can be used to

     ruby ./extconf.rb

   and create a Makefile that will be setup for the mingw toolchain but
   producing output that will be compatible with the vc++ compiled
one-click
   ruby

   step five : compile any third party libs using mingw

   step six : compile any ruby extensions against these as normal


has anyone done anything like this?  does it sound resonable?

kind regards.

-a
Dave L. (Guest)
on 2006-04-08 21:59
(Received via mailing list)
On 4/8/06, removed_email_address@domain.invalid 
<removed_email_address@domain.invalid> wrote:
> so i need to compile a bunch of stuff on windows.  some third party stuff and
> ruby extensions to those third party libs.  everything i do __must__ be
> compatible with the one-click installer, here's what i'm thinking might be a
> good approach:
>
> [snip]
>
> has anyone done anything like this?  does it sound resonable?

This is close to how I build the ruby-postgres win32 gem.  I have
MingW and MSYS installed,  which I used to build, *and install* ruby
1.8.4.  simple as:

./configure --prefix=c:/mingw/ruby
make
make install

this keeps the two ruby installs seperate.

and to build the extension:

export PATH="c:/mingw/ruby/bin:$PATH"
cd to/ruby/extension
ruby extconf.rb
make
gem build *.gemspec

to install the extension (to the one-click installer ruby in c:/ruby),
I open up a new term, which has c:/ruby/bin in the $PATH, and run `gem
install ...`.  In your case, you would run `make install`, which
should install to your one-click installation.  I run all of this from
an MSYS term, except for the last step of installing to one-click
ruby, where I use a windows command term.

Dave
unknown (Guest)
on 2006-04-08 22:29
(Received via mailing list)
On Sun, 9 Apr 2006, Dave L. wrote:

> This is close to how I build the ruby-postgres win32 gem.  I have
>
> for the last step of installing to one-click ruby, where I use a windows
> command term.

cool.  i was just doing a

   ./confgure --prefix=c:/mingw/ruby --with-gcc='gcc -mno-cygwin'
--enable-shared

now!

seems like i'm on the right track.  the only drawback i can see to this
approach is that any third party lib must also compile against the
'cygwin-less' mingw setup (or a pure mingw setup) and that's quite a
hope ;-)

thanks for the info.

fyi.  i just got narray to compile for the one-click using this
approach.

-a
unknown (Guest)
on 2006-04-08 23:52
(Received via mailing list)
On Sun, 9 Apr 2006, Dave L. wrote:

> This is close to how I build the ruby-postgres win32 gem.  I have
>
> an MSYS term, except for the last step of installing to one-click
> ruby, where I use a windows command term.

have you done this against the __latest__ one-click installer?  my libs
are
blowing up with bad entry points!?

-a
Dave L. (Guest)
on 2006-04-09 00:10
(Received via mailing list)
On 4/8/06, removed_email_address@domain.invalid 
<removed_email_address@domain.invalid> wrote:
> have you done this against the __latest__ one-click installer?  my libs are
> blowing up with bad entry points!?

I'm using ruby184-16_rc1.

what do you errors look like?

Dave
unknown (Guest)
on 2006-04-09 00:26
(Received via mailing list)
On Sun, 9 Apr 2006, Dave L. wrote:

> On 4/8/06, removed_email_address@domain.invalid <removed_email_address@domain.invalid> 
wrote:
>> have you done this against the __latest__ one-click installer?  my libs are
>> blowing up with bad entry points!?
>
> I'm using ruby184-16_rc1.
>
> what do you errors look like?

well - the machine just froze (suprise suprise) but essentially a
failing
entry point in a shared lib...

-a
Mauricio F. (Guest)
on 2006-04-09 15:31
(Received via mailing list)
On Sun, Apr 09, 2006 at 01:36:06AM +0900, removed_email_address@domain.invalid 
wrote:
> so i need to compile a bunch of stuff on windows.  some third party stuff
> and ruby extensions to those third party libs.  everything i do __must__ be
> compatible with the one-click installer, here's what i'm thinking might be a
> good approach:
[...]
>   step four : clobber the one-click installer's rbconfig.rb with the one
>   just created!  the idea here is that this rbconfig can be used to
>
>     ruby ./extconf.rb
>
>   and create a Makefile that will be setup for the mingw toolchain but
>   producing output that will be compatible with the vc++ compiled one-click
>   ruby

>   step five : compile any third party libs using mingw
>
>   step six : compile any ruby extensions against these as normal
>
> has anyone done anything like this?  does it sound resonable?

A couple years ago I proceeded similarly to build ruby-serialport:
actually, I
built and installed (separately) ruby under msys, and then copied the
extensions so the one-click build would see them, but that's largely
equivalent to what you described. That was with an older one-click
distro
before Curt began building it against an incompatible runtime (so the
situation was the same as now, after the shift to the mswin32 build).

I've also had some success cross-compiling with mingw:
 http://eigenclass.org/hiki.rb?cross+compiling+rcovrt

In the past, I also cross-compiled PDCurses, the curses extension,
GraphicsMagick, etc... It sometimes required some ad-hoc modifications
in the
build systems, but none took more than ~10-15 minutes and they would
have
been easy to script had I wanted to automate builds.
Kris L. (Guest)
on 2006-06-23 15:42
unknown wrote:
> so i need to compile a bunch of stuff on windows.  some third party
> stuff and
> ruby extensions to those third party libs.  everything i do __must__ be
> compatible with the one-click installer, here's what i'm thinking might
> be a
> good approach:
>
>

You are using MSYS right?

I can get this to compile ruby, but it will not run webrick, it just
returns to the command prompt.
unknown (Guest)
on 2006-06-23 19:06
(Received via mailing list)
On Fri, 23 Jun 2006, Kris L. wrote:

> You are using MSYS right?
>
> I can get this to compile ruby, but it will not run webrick, it just returns
> to the command prompt.

this is due to threading issues on windows i think.  i've successfully
compiled ruby, gsl, narray, and rb-gsl using this approach now.  the gsl
binaries are here now

   http://codeforpeople.com/lib/ruby/
   http://codeforpeople.com/lib/ruby/rb-gsl-win/

so far i haven't had any issue.

i plan to write this up soon.  i'll test webrick on my platform soon.

regards.

-a
Curt H. (Guest)
on 2006-06-24 08:35
(Received via mailing list)
On 6/23/06, removed_email_address@domain.invalid 
<removed_email_address@domain.invalid> wrote:
> >>
> binaries are here now
> -a
> --
> suffering increases your inner strength.  also, the wishing for suffering
> makes the suffering disappear.
> - h.h. the 14th dali lama



Ara, I've had conflisting reports about the compatibility of mingw and
vc++6. So, I don't really know the answer.

The compiler situation under Windows has become a miniature nightmare.
The
current release (one its goes final) will be the last one built with
vc++.
Starting with whatever Matz releases this Xmas, I'm going to move to
mingw.

Curt
John-Mason P. Shackelford (Guest)
on 2006-06-24 08:59
(Received via mailing list)
I understand from
http://eigenclass.org/hiki.rb?ruby+1.8.5+release+schedule that our
next release will show up in August. It may sound crazy, but I'd
rather see no 1.8.4 stable OCI on VC6 with a ming or current VC++
version (now that the compiler is freely available) release in August.
If an OCI is released, extensions will have to support it given the
size of the OCI user base. VC6 is no longer available and there are
significant compatibility issues not among the VC++ versions and
mingw. If we switch to yet another compiler as early as August or even
as early as Christmas 2006 for that matter, we experience the
compatibility issue all over again. It is not out of the question that
a user would have to select one of three binary versions of an
extension just to get it running on their installed OCI which, to my
mind, is unacceptable.

--
John-Mason Shackelford

Software Developer
Pearson Educational Measurement

2510 North Dodge St.
Iowa City, IA 52245
ph. 319-354-9200x6214
removed_email_address@domain.invalid
http://pearsonedmeasurement.com
Curt H. (Guest)
on 2006-06-24 10:27
(Received via mailing list)
On 6/23/06, John-Mason P. Shackelford <removed_email_address@domain.invalid> 
wrote:
> as early as Christmas 2006 for that matter, we experience the
>
> 2510 North Dodge St.
> Iowa City, IA 52245
> ph. 319-354-9200x6214
> removed_email_address@domain.invalid
> http://pearsonedmeasurement.com
>
>
This is the problem. vc++6 is no longer available, yet nearly all of the
binary extensions are only available in vc++6. Last year's disaster with
vc++7 is why we returned to vc++6. However its lack of availability and
the
realization that this will be an ongoing problem is why we'll be going
with
mingw.

However, I was not aware (until now) of the 1.8.5 schedule. That is too
soon
for a mingw release (too much work to be be done and not enough time).
If
that happens, then 1.8.5 would also be a vc++6 release.

Curt
This topic is locked and can not be replied to.