Rubyinstaller devel - Oct 2007 - Did you succeed on Ruby-MinGW compilation?

For some reason the mingw gcc is having trouble with finding headers and
libs.  It is reasonably annoying :)

$ cat test.c
#include <zlib.h>

Melissa at MELISSA-PACK /c/take3/ruby/ext/zlib
$ gcc test.c
test.c:1:18: zlib.h: No such file or directory

Melissa at MELISSA-PACK /c/take3/ruby/ext/zlib
$ ls /usr/local/include
GraphicsMagick iconv.h libcharset.h localcharset.h zconf.h zlib.h

It''s there! I see it!

Anyway gcc is loading its own directories--I think the problem is that I
unzip things within the ''msys'' framework, when in reality I
should unzip
them all within the mingw subdirectory.  Man that is so retarded!


I am also having some serious difficulty getting openssl to compile, still.
 I honestly don''t know how to do it!

On yours does it actually compile anything after it says "compiling
zlib" or
what not?


> > We used it at the office (my company) and for our consulting services.
> > > Since last year I''m struggling to get a working, faster
environment
> > > for Ruby on Windows.

Amen to that.

> > Honestly I don''t like this small struggling community of ruby
for
> > windows users split again, so I''ll love have you on the team
and get a
> > faster product.
I can help out in a limited way :)


No problem, there are tools (free) that allow us create MSI
installers. WiX and WiXTool.


Nice.

Does ruby actually run faster in 64 bit modes?  I guess the good thing about
it is that you can use more memory--like...you know...more than 4G or what
not, so I guess being able to eventually compile in it would be nice. Do you
think mingw will cut the bill for that?

> > - Modular design: currently as I commented to Curt, the installer is a
> > giant beast that lack testing and modularity -- even using the
> > rakefile -- it is a huge one too difficult to debug.
>
> There would probably be the natural way of dividing it
> to be ''main build'' ''internal
ext''s'' and
> ''gems'' (which is, of course, nuts since gems
> is almost everything)
>I was talking about the core of the installer, since beside Ruby it
>needs the dependencies like OpenSSL, Zlib, Gettext, Iconv, readline,
>etc. available at install time.
So you want people to keep track of updates to these libraries and integrate
them?  Not too much
problem.  It seems like once you get a single build running
(anywhere), then updating that build would be cake.

>In that way, we could "modularize" or pluginize the installer and
>create, without too much hassle new installers for the different
>interpreters.
>Simply the gem creation and building on Windows is one of the goals.
One option is to include a limited build with the distro (like just
gcc.exeor what have you), and then gem creators can have it build
still.
> > - Developer ecosystem friendliness: With the update to VC8 or MinGW,
> > the new Ruby distro will be more friendly to developers, so you will
> > need just a few instructions to get started, instead the whole problem
> > we are dealing right now.
>
> I still like the ''one click installer'' idea, at
> least personally.  Then tell them to use
> gems (and how) and they are good to go :)
The One Click installer idea is still present, I meant provide better
documentation or support to Gem/Ruby developers with the new "distro".
>The survey will cover a "User/Developer" profile, so we could get
a
>picture of the usage of Ruby on Windows.
 Asking for advice ''which do you prefer'' would be nice, too.
> 2) Have a working VC8, mingw, and VC6 (with extensions?) side by
side.  Err
> rather maybe just VC6 and a mingw build side by side so that people can
> download them and tell us which one they like more.  Give them the choice
to
> experiment and see if they like one more than another, then pursue that
> path.  If no opinion then pick one :)
>There is a official build with VC6... and is the one that powers OCI
currently.
>VC8 should be the option since is freely available (and VC6 no longer).
Once I get one working with all the libs I''d be happy to post it.
> Mingw feels faster than VC6--that I can tell.  It does.  I like it :)
Of course, VC8 feels faster than VC6 too.
We should considerer the whoe spectrum and not just the speed of
things, stability is important.
>A lot of improvements are made to the ruby trunk regarding VC8
>compatibility, and MinGW, on the contrary, haven''t improveed
(haven''t
>seen commits about it) for the past year.
>That is a important thing, and shouldn''t be ignored, since
Reinventing
>the wheel on a project like this is something huge.
Either way''s good for me.
>Last, but no least, MinGW is more close to what vanilla-gcc is
>available under Linux (and similar to OSX too -- afaik), we
shouldn''t
>discard that knowledge neither...
>Is a difficult choice, but someone must take it :-)
> Also it would be nice to run some really nice tests between all the
versions
> to see what people are getting into :)
I don''t know what you imply with "nice tests". If
you''re just talking
about performance, even is important, stability came first.

Some tests that show file I/o and socket I/o would be nice.  Of course it
MUST be stable--any real distro.
>(You already show me that RMagick is doing some weird things on MinGW).
Yeah we need to resolve those things before maybe...even mentioning it as a
real alternative?  I can let you know when I finally get everything working.
 The learning curve is somewhat bad here.

I don''t understand exactly how this msys versus normal directory
structure
thing is actually supposed to work.  I think that the msys people envision
you only using their tools from the console
window or something? Huh? I just don''t get it.
> If it were my personal choice I''d probably go for mingw, because
then gem
> creators in Linux aren''t "shooting in the dark" for the
windows side of
> their gems.
On every gem or lib that I use I provided patches to ease the problems
with Windows platform, most due linux developers disregards things
like cross-platform, and code things for their own distro.

I sometimes have found code that couldn''t get it working on other
distro that wasn''t the original used by the author''s gem.
> Of course, the real reason I''d suggest that is that I have an
> (almost) working build of mingw, and not a VC environment at all (I wanted
> speed!).
Again, speed vs. stability. Getting the build environment for VC8
isn''t too complicated either, but more complex than MinGW it is.

A note: VC8 is free, as I commented before.


The only drawback I see to mingw is that it probably ain''t going to
64-bit
anytime soon.  And we need to make sure it works.  Then again I''ve
never
even used it, so I have no point of reference.  I''d say offer them both
side-by-side for awhile (one for backwards compatibility), and see which one
people like.  I think after they see that mingw is faster they''ll all
just
use it...like automatically.


Good luck to all of us!
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/rubyinstaller-devel/attachments/20071022/2e4c2c26/attachment.html

All right I finally hacked through to a working copy of mingw ''with all
the
fixings'' of Ruby 1.8.6''s "latest stable release"
version.
I have posted the final ruby executable with gems and zlib etc. etc. here
http://doachristianturndaily.info/roger/ruby_distro/

If anybody wants to try it out and give feedback that would be great!
I will try and post a smaller version of the existing downloadable zipfile
soon (it may or may not be there by the time you read this email).
Thanks for Luis for support, and for obscure emails in newslists around the
world for tidbits of information.  Wish I could say it had been easy.

To install:
unzip the ruby_mingw4.zip file to c:\ (or wherever)
then make sure (in this example) c:\ruby_mingw4\bin is at the front of your
path.
Verify by running ruby -v
-- should say mingw
Now you can install gems by using gem list, gem install XXX (package name
there).
and see what''s installed
gem list

There are a grundle of packages pre-installed, you may want to uninstall
some, a la
gem list
gem uninstall rails -v 1.2.5 (or what not).
gem install rails -v 1.2.3 (to install rails 1.2.3, and uninstall 1.2.5)

You may also want to set the environment variable RUBY_OPT=rubygems (or
whatever it is exactly) for it to execute "require
''rubygems''" before each
script.

This release appears to work with rails on windows, using a lot of
libraries. Good luck!
-Roger
Sponsored in part by mokisystems.com web development and
upillar.com online vehicle sales
and doachristianturndaily.info


Remember to have a great day!

On 10/22/07, Luis Lavena <luislavena at gmail.com>
wrote:
>
> On 10/22/07, Roger Pack <rogerpack2005 at gmail.com> wrote:
> > Turns out that whenever you build anything within mingw, you must
> specify
> > "build it to /mingw" or "--prefix=c:/mingw" or it
will install it as if
> it''s
> > an internal MSYS library or something.  Which was very surprising for
a
> > newbie.  Ahh well.
> > After finally hacking I figured out "wait a second! you can
actually
> copy
> > extensions from the old msvc install into the new mingw one and they
> work"
> > (so I don''t actually even "have" to compile
everything now).  And,
> voila.
> > Now I think everything works.
>
> I told you :-)
>
> > Turns out the rmagick bug is a ''legacy bug'' that is
avoided by
> installing
> > their binary rmagick for windows gem.  Problem was theirs, and they
> fixed
> > it--I just didn''t think it would still be there. Ahh well.
>
> Yeah, RMagick is a so darn beast, they should use the official
> ImageMagick... still don''t get why they didn''t patched
officially.
>
> > So now I finally have a working mingw! Rails works!  And it''s
> faster!  And
> > doesn''t seem to complicated to setup.
>
> Hehehe, again, I told you so... wasn''t complicated, you just need
to
> invest some hours and get a nice speed (boost) ;-)
>
> > I''ll finalize my notes probably sometime (and keep them
online at the
> > aforementioned wiki for now).
> >
>
> That will be excellent.
>
> > I''ll also post a copy of my win32 stuff--should I announce it
on the
> list so
> > people can experiment with it? See if they like it?
>
> That will be good too, since recreating the whole thing is a pain,
> sharing it with other win32-users will probably show up some failing
> things that you didn''t notice.
>
> > I also did notice that there are some experiment 64-bit stuff for
mingw,
> > which is...good, but...a little bit scary.
>
> Yeah, I commented that too. mingw-x64 is too experimental right now,
> mostly the way Windows x64 do with signing and manifest things...
>
> But still, Ruby 1.8 isn''t compatible with that, yet.
>
> > Anyway things are going well.
> > I will post my stuff when it gets uploaded in about 30 minutes (turned
> out
> > rather large).
>
> Remove documentation! the RI and RDOC stuff eats a lot of space (I had
> my distro under 8MB)...
>
> > Thanks for your help!
>
> No problem, you''re welcome.
>
> Please share this back with the community.
>
> --
> Luis Lavena
> Multimedia systems
> -
> Leaders are made, they are not born. They are made by hard effort,
> which is the price which all of us must pay to achieve any goal that
> is worthwhile.
> Vince Lombardi
>

-- 
-Roger Pack
I like belief. http://www.google.com/search?q=free+bible
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/rubyinstaller-devel/attachments/20071022/c6851add/attachment.html