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
on 08.04.2006 18:36
on 08.04.2006 19:59
On 4/8/06, ara.t.howard@noaa.gov <ara.t.howard@noaa.gov> 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
on 08.04.2006 20:29
On Sun, 9 Apr 2006, Dave Lee 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
on 08.04.2006 21:52
On Sun, 9 Apr 2006, Dave Lee 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
on 08.04.2006 22:10
On 4/8/06, ara.t.howard@noaa.gov <ara.t.howard@noaa.gov> 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
on 08.04.2006 22:26
On Sun, 9 Apr 2006, Dave Lee wrote: > On 4/8/06, ara.t.howard@noaa.gov <ara.t.howard@noaa.gov> 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
on 09.04.2006 13:31
On Sun, Apr 09, 2006 at 01:36:06AM +0900, ara.t.howard@noaa.gov 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.
on 23.06.2006 13: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.
on 23.06.2006 17:06
On Fri, 23 Jun 2006, Kris Leech 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
on 24.06.2006 06:35
On 6/23/06, ara.t.howard@noaa.gov <ara.t.howard@noaa.gov> 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
on 24.06.2006 06:59
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 john-mason.shackelford@pearson.com http://pearsonedmeasurement.com
on 24.06.2006 08:27
On 6/23/06, John-Mason P. Shackelford <jpshack@gmail.com> wrote: > as early as Christmas 2006 for that matter, we experience the > > 2510 North Dodge St. > Iowa City, IA 52245 > ph. 319-354-9200x6214 > john-mason.shackelford@pearson.com > 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