Windows gurus i beseech you


#1

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


#2

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


#3

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 :wink:

thanks for the info.

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

-a


#4

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


#5

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


#6

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


#7

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.


#8

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.


#9

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


#10

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


#11

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


#12

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