From fabioakita at gmail.com  Thu Aug  7 09:47:06 2008
From: fabioakita at gmail.com (Fabio Akita)
Date: Thu, 7 Aug 2008 10:47:06 -0300
Subject: [Rubyinstaller-devel] MingW VS VS6
Message-ID: <F436F7D5-5947-467D-AF5E-A30DFE30DB9D@gmail.com>

I've been recommending people to use the newest Ruby Installer, which  
uses MingW to build itself but install the old VS6 compiled gems (such  
as sqlite3-ruby), mainly using the --platform=mswin32 with the gem  
install command.

Then someone asked me if this was a good idea because there could be  
some binary level incompatibility between the interpreter and  
libraries compilations.

Does anyone know of any problematic case about this, or it is not a  
problem?

From luislavena at gmail.com  Thu Aug  7 09:58:23 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Thu, 7 Aug 2008 15:58:23 +0200
Subject: [Rubyinstaller-devel] MingW VS VS6
In-Reply-To: <F436F7D5-5947-467D-AF5E-A30DFE30DB9D@gmail.com>
References: <F436F7D5-5947-467D-AF5E-A30DFE30DB9D@gmail.com>
Message-ID: <71166b3b0808070658t6e234cb1gd54cc2b615ad44d9@mail.gmail.com>

On Thu, Aug 7, 2008 at 3:47 PM, Fabio Akita <fabioakita at gmail.com> wrote:
> I've been recommending people to use the newest Ruby Installer, which uses
> MingW to build itself but install the old VS6 compiled gems (such as
> sqlite3-ruby), mainly using the --platform=mswin32 with the gem install
> command.
>
> Then someone asked me if this was a good idea because there could be some
> binary level incompatibility between the interpreter and libraries
> compilations.
>
> Does anyone know of any problematic case about this, or it is not a problem?

Some people say that there is no problem, since MinGW states to be
binary compatible with VC6.

On the other hand, sometimes depending on the type of that being
exchanged between the linked libraries or the program itself, it send
data wrongly aligned, which produces a segfault.

I got hit by this dealing with MySQL gem... several times. MySQL gem
built with VC6 and MinGW installation.

For that purpose I created a mingw gem that you can install from here:

gem install mysql --source http://gems.rubyinstaller.org

Also you will find there a win32console compilation based on my fork in GitHub.

Some gems can be easily built with the DevKit, like RedCloth 4 without
external dependencies.

There are other problems about platforms like RUBY_PLATFORM regexp
that can interfere with the actual code execution.

So sometimes issuing a --platform=mswin32 will not fix the issue, but
generate some random errors (like Mongrel 1.1.5 a few weeks ago, mea
culpa).

-- 
Luis Lavena
AREA 17
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

From mhodgson at gmail.com  Thu Aug  7 11:49:04 2008
From: mhodgson at gmail.com (Mike Hodgson)
Date: Thu, 7 Aug 2008 11:49:04 -0400
Subject: [Rubyinstaller-devel] MingW VS VS6
In-Reply-To: <71166b3b0808070658t6e234cb1gd54cc2b615ad44d9@mail.gmail.com>
References: <F436F7D5-5947-467D-AF5E-A30DFE30DB9D@gmail.com>
	<71166b3b0808070658t6e234cb1gd54cc2b615ad44d9@mail.gmail.com>
Message-ID: <6dae68ac0808070849g1228e268ib382370565b67f55@mail.gmail.com>

On Thu, Aug 7, 2008 at 9:58 AM, Luis Lavena <luislavena at gmail.com> wrote:
> On Thu, Aug 7, 2008 at 3:47 PM, Fabio Akita <fabioakita at gmail.com> wrote:
>> I've been recommending people to use the newest Ruby Installer, which uses
>> MingW to build itself but install the old VS6 compiled gems (such as
>> sqlite3-ruby), mainly using the --platform=mswin32 with the gem install
>> command.
>>
>> Then someone asked me if this was a good idea because there could be some
>> binary level incompatibility between the interpreter and libraries
>> compilations.
>>
>> Does anyone know of any problematic case about this, or it is not a problem?
>
> Some people say that there is no problem, since MinGW states to be
> binary compatible with VC6.
>
> On the other hand, sometimes depending on the type of that being
> exchanged between the linked libraries or the program itself, it send
> data wrongly aligned, which produces a segfault.
>
> I got hit by this dealing with MySQL gem... several times. MySQL gem
> built with VC6 and MinGW installation.
>
> For that purpose I created a mingw gem that you can install from here:
>
> gem install mysql --source http://gems.rubyinstaller.org
>
> Also you will find there a win32console compilation based on my fork in GitHub.
>
> Some gems can be easily built with the DevKit, like RedCloth 4 without
> external dependencies.
>
> There are other problems about platforms like RUBY_PLATFORM regexp
> that can interfere with the actual code execution.
>
> So sometimes issuing a --platform=mswin32 will not fix the issue, but
> generate some random errors (like Mongrel 1.1.5 a few weeks ago, mea
> culpa).

Hi folks,

Sort of off-topic, but I've built a mingw gem for sqlite3-ruby, which
you can download here:

http://mikehodgson.com/sqlite3-ruby-1.2.2-x86-mingw32.gem


Mike

From larsch at belunktum.dk  Mon Aug 11 13:11:33 2008
From: larsch at belunktum.dk (Lars Christensen)
Date: Mon, 11 Aug 2008 19:11:33 +0200 (Romance Standard Time)
Subject: [Rubyinstaller-devel] News for OpenSSL build
In-Reply-To: <71166b3b0807251833g2ddce3fcg3e26ce9367d2a093@mail.gmail.com>
References: <71166b3b0807251833g2ddce3fcg3e26ce9367d2a093@mail.gmail.com>
Message-ID: <Pine.WNT.4.64.0808101505370.2584@cookie>


On Sat, 26 Jul 2008, Luis Lavena wrote:

> After circumvent the issues with symlinks in the packages and find the
> proper steps to build it, I managed to create a new recipe for it.

I overcame my perl-phobia and decided to take a look at why the provided 
scripts failed, and ended up with just two issues:

* CR/LF issues. The mk1mk.pl script reads from MINFO and gets the \r\n 
instead of just \n, so the regexps fail silently.

* When mingw32-make is run with MSYS in the PATH, it defaults to calling 
sh.exe instead of cmd.exe (copy/cp issue).

I worked around the above issues by tweaking mk1mf.pl (tweaking the 
regexp) and mingw32.bat (adding SHELL=cmd.exe when invoking mingw32-make). 
This seems to work, even with DLL. Other than those two changes, it builds 
cleanly in the standard way.

I've pushed my changes to github:

http://github.com/larsch/rubyinstaller/tree/proper-openssl-alt

However, I noticed that openssl.so still gets statically linked. I'm not 
sure why this is. I'll try and investigate. I seems to happen with my 
previous attempts with ActiveState and Strawberry too.

-- 
Lars


From luislavena at gmail.com  Tue Aug 12 05:30:54 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Tue, 12 Aug 2008 11:30:54 +0200
Subject: [Rubyinstaller-devel] News for OpenSSL build
In-Reply-To: <Pine.WNT.4.64.0808101505370.2584@cookie>
References: <71166b3b0807251833g2ddce3fcg3e26ce9367d2a093@mail.gmail.com>
	<Pine.WNT.4.64.0808101505370.2584@cookie>
Message-ID: <71166b3b0808120230x3373cff7l1be634b9c3bff86@mail.gmail.com>

On Mon, Aug 11, 2008 at 7:11 PM, Lars Christensen <larsch at belunktum.dk> wrote:
>
> On Sat, 26 Jul 2008, Luis Lavena wrote:
>
>> After circumvent the issues with symlinks in the packages and find the
>> proper steps to build it, I managed to create a new recipe for it.
>
> I overcame my perl-phobia and decided to take a look at why the provided
> scripts failed, and ended up with just two issues:
>

Welcome to the club!

> * CR/LF issues. The mk1mk.pl script reads from MINFO and gets the \r\n
> instead of just \n, so the regexps fail silently.
>
> * When mingw32-make is run with MSYS in the PATH, it defaults to calling
> sh.exe instead of cmd.exe (copy/cp issue).
>
> I worked around the above issues by tweaking mk1mf.pl (tweaking the regexp)
> and mingw32.bat (adding SHELL=cmd.exe when invoking mingw32-make). This
> seems to work, even with DLL. Other than those two changes, it builds
> cleanly in the standard way.
>
> I've pushed my changes to github:
>
> http://github.com/larsch/rubyinstaller/tree/proper-openssl-alt
>
> However, I noticed that openssl.so still gets statically linked. I'm not
> sure why this is. I'll try and investigate. I seems to happen with my
> previous attempts with ActiveState and Strawberry too.
>

Did you had change to test the proper-openssl branch I created?

http://github.com/luislavena/rubyinstaller/tree/proper-openssl

I got the shared lib (dll) building properly, but I need to check your
work too, so we can merge them into master and move forward soon.

Dunno you guys, but I want to release a Runtime version soon (like in 2 weeks?)

Regards and thank you for your hard work.
-- 
Luis Lavena
AREA 17
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

From larsch at belunktum.dk  Tue Aug 12 09:06:48 2008
From: larsch at belunktum.dk (Lars Christensen)
Date: Tue, 12 Aug 2008 15:06:48 +0200 (Romance Standard Time)
Subject: [Rubyinstaller-devel] News for OpenSSL build
In-Reply-To: <71166b3b0808120230x3373cff7l1be634b9c3bff86@mail.gmail.com>
References: <71166b3b0807251833g2ddce3fcg3e26ce9367d2a093@mail.gmail.com>
	<Pine.WNT.4.64.0808101505370.2584@cookie>
	<71166b3b0808120230x3373cff7l1be634b9c3bff86@mail.gmail.com>
Message-ID: <Pine.WNT.4.64.0808121443310.1680@cookie>

On Tue, 12 Aug 2008, Luis Lavena wrote:

>> However, I noticed that openssl.so still gets statically linked. I'm not
>> sure why this is. I'll try and investigate. I seems to happen with my
>> previous attempts with ActiveState and Strawberry too.
>>
>
> Did you had change to test the proper-openssl branch I created?
>
> http://github.com/luislavena/rubyinstaller/tree/proper-openssl

Yes indeed, and it worked very well. My reason for looking into this again 
was primarily to understand the build failures better, but also in hope of 
a minimal build method that is as close as possible to the officially 
supported method by the OpenSSL team.

To be honest, I personally would prefer the ActiveState or Strawberry 
solution since it is the only official provided by the OpenSSL team, but I 
understand that the bloat is undisirable in rubyinstaller. I'm certainly 
not dimissing your approach, just looking for enlightenment and possible 
alternatives.

I think that RubyInstaller should be as transparent as possible about what 
it does, so that it is (a) as close to official release & procedures as 
possible, and (b) whatever custom changes there are easily identifiable. 
The reason for this is an issue of trust. Its the same reason I would 
avoid the Shining Light builds [1]. Its a matter of trust. Breaches, and 
not least, human errors[2], do occur.

[1] http://www.slproweb.com/products/Win32OpenSSL.html
[2] http://www.metasploit.com/users/hdm/tools/debian-openssl/

> I got the shared lib (dll) building properly, but I need to check your 
> work too, so we can merge them into master and move forward soon.

Is this commit ece49e8a5131a03f7? (Just to understand)

> Dunno you guys, but I want to release a Runtime version soon (like in 2 weeks?)
>
> Regards and thank you for your hard work.

Same to you Luis!

Rgds,
Lars


From larsch at belunktum.dk  Fri Aug 15 14:01:42 2008
From: larsch at belunktum.dk (Lars Christensen)
Date: Fri, 15 Aug 2008 20:01:42 +0200 (Romance Standard Time)
Subject: [Rubyinstaller-devel] Working with multiple Ruby versions
Message-ID: <Pine.WNT.4.64.0808151650390.2980@cookie>

Hi,

I'd like the option to work with multiple ruby versions in the same 
rubyinstaller directory, primarily to speed up 'rake' operations and to 
avoid multiple downloads, extracts, etc. Also, the current 'cp' operation 
on the ruby sources code when checking out from SVN is very slow.

My suggestion is to put the source/build/install targets into separate 
directories, depending on the origin and version of the Ruby source.

For example, when pulling from SVN:

sandbox/ruby_source/svn/tags/v1_8_6_114
sandbox/ruby_build/svn/tags/v1_8_6_114
sandbox/ruby_mingw/svn/tags/v1_8_6_114

Or a branch:

sandbox/ruby_source/svn/branches/ruby_1_8

Or from the tarball:

sandbox/ruby_source/ruby-1.8.6-p114

I've pushed some changes to 
http://github.com/larsch/rubyinstaller/commits/nocopycheckout2/ which 
implements the above. You can set the SVN URL in config/ruby_installer.rb, 
and it will then decide a path on it's own, from the contents of the URL. 
This can still be overridden by setting the options, e.g. 
:checkout_target, but by default they are left out and generated by the 
script.

Lars


From luislavena at gmail.com  Sat Aug 23 03:25:51 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Sat, 23 Aug 2008 09:25:51 +0200
Subject: [Rubyinstaller-devel] Working with multiple Ruby versions
In-Reply-To: <Pine.WNT.4.64.0808151650390.2980@cookie>
References: <Pine.WNT.4.64.0808151650390.2980@cookie>
Message-ID: <71166b3b0808230025y3fff1aa8vea303f25abab1c5b@mail.gmail.com>

On Fri, Aug 15, 2008 at 8:01 PM, Lars Christensen <larsch at belunktum.dk> wrote:
> Hi,
>

Hey Lars!

Sorry took me so long get back to you, kind of hectic lately.

> I'd like the option to work with multiple ruby versions in the same
> rubyinstaller directory, primarily to speed up 'rake' operations and to
> avoid multiple downloads, extracts, etc. Also, the current 'cp' operation on
> the ruby sources code when checking out from SVN is very slow.
>

I was thinking that we need to establish a "label" for those different
version, and also get rid of the checkout and copy procedure, whcih is
suboptimal like you said.

> My suggestion is to put the source/build/install targets into separate
> directories, depending on the origin and version of the Ruby source.
>
> For example, when pulling from SVN:
>
> sandbox/ruby_source/svn/tags/v1_8_6_114
> sandbox/ruby_build/svn/tags/v1_8_6_114
> sandbox/ruby_mingw/svn/tags/v1_8_6_114
>
> Or a branch:
>
> sandbox/ruby_source/svn/branches/ruby_1_8
>
> Or from the tarball:
>
> sandbox/ruby_source/ruby-1.8.6-p114
>

Hmn, I was thinking something more in the lines of what multiruby
does, but with a twist:

sandbox/ruby_{version}/source
sandbox/ruby_{tag,branch}/build
sandbox/ruby_{tag,branch}/package

version can be tag, branch, tarball signatures, like 1_8 (for branch)
or 1_8_6_114 for tag and 1.8.6-p114 for tarball.

In any case, I'm considering labeling those version as stable, current
and candidate for ruby18 and ruby19 ;-)

> I've pushed some changes to
> http://github.com/larsch/rubyinstaller/commits/nocopycheckout2/ which
> implements the above. You can set the SVN URL in config/ruby_installer.rb,
> and it will then decide a path on it's own, from the contents of the URL.
> This can still be overridden by setting the options, e.g. :checkout_target,
> but by default they are left out and generated by the script.
>

Didn't had time to take a look, gut I think that
config/ruby_installer.rb purpose hit another wall issue. When I first
designed it was not ready to handle all this different context, and
turned to be smaller for what we are trying to do.

I've been playing with a rewrite of the task, in the lines of the
openssl one, but with another twist.

a YAML file that specify a single download, a checkout or series of
files (packages) for different versions like stable, current and
candidate.

Then, a parametrized rake task for ruby18 which always depend on gcc,
zlib, openssl versions. Unless you specify, it always build stable.

If you want a different version, just say: rake ruby18[candidate] and
you can also tweak openssl[current] instead of the stable default.

ruby18 is not depending on a specific openssl task, but on also a
parametrized one. Maybe is stupid, I know :-P

Thanks Lars for presenting those scenarios, will be cool if we have a
formal "meeting" to discuss next steps (Gordon, you and me) --- and
anyone that want to join us! :-D

-- 
Luis Lavena
AREA 17
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

From larsch at belunktum.dk  Sun Aug 24 06:55:26 2008
From: larsch at belunktum.dk (Lars Christensen)
Date: Sun, 24 Aug 2008 12:55:26 +0200 (Romance Standard Time)
Subject: [Rubyinstaller-devel] Working with multiple Ruby versions
In-Reply-To: <71166b3b0808230025y3fff1aa8vea303f25abab1c5b@mail.gmail.com>
References: <Pine.WNT.4.64.0808151650390.2980@cookie>
	<71166b3b0808230025y3fff1aa8vea303f25abab1c5b@mail.gmail.com>
Message-ID: <Pine.WNT.4.64.0808241251050.3816@cookie>


On Sat, 23 Aug 2008, Luis Lavena wrote:

>> I'd like the option to work with multiple ruby versions in the same
>> rubyinstaller directory, primarily to speed up 'rake' operations and to
>> avoid multiple downloads, extracts, etc. Also, the current 'cp' operation on
>> the ruby sources code when checking out from SVN is very slow.
>>
>
> I was thinking that we need to establish a "label" for those different
> version, and also get rid of the checkout and copy procedure, whcih is
> suboptimal like you said.

> sandbox/ruby_{version}/source
> sandbox/ruby_{tag,branch}/build
> sandbox/ruby_{tag,branch}/package

That appears more clean to me. I'll update my approach.

> version can be tag, branch, tarball signatures, like 1_8 (for branch)
> or 1_8_6_114 for tag and 1.8.6-p114 for tarball.
>
> Didn't had time to take a look, gut I think that
> config/ruby_installer.rb purpose hit another wall issue. When I first
> designed it was not ready to handle all this different context, and
> turned to be smaller for what we are trying to do.

Yes, it does seem abit awkward. Some parameters can be derived from 
others, such as paths from SVN urls etc. That is not so clean when 
creating OpenStructs.

> I've been playing with a rewrite of the task, in the lines of the
> openssl one, but with another twist.
>
> a YAML file that specify a single download, a checkout or series of
> files (packages) for different versions like stable, current and
> candidate.
>
> Then, a parametrized rake task for ruby18 which always depend on gcc,
> zlib, openssl versions. Unless you specify, it always build stable.
>
> If you want a different version, just say: rake ruby18[candidate] and
> you can also tweak openssl[current] instead of the stable default.

Is the [] syntax something from Rake?

> Thanks Lars for presenting those scenarios, will be cool if we have a
> formal "meeting" to discuss next steps (Gordon, you and me) --- and
> anyone that want to join us! :-D

Sure. What form?


Lars





From mhodgson at gmail.com  Wed Aug 27 18:49:26 2008
From: mhodgson at gmail.com (Mike Hodgson)
Date: Wed, 27 Aug 2008 18:49:26 -0400
Subject: [Rubyinstaller-devel] Trying to compile sqlite3
In-Reply-To: <71166b3b0807261311g55efa74cpdd5c0bfc733babf9@mail.gmail.com>
References: <43bfd1100807261237q284e5fd4k90e0180e8a5afa21@mail.gmail.com>
	<71166b3b0807261311g55efa74cpdd5c0bfc733babf9@mail.gmail.com>
Message-ID: <6dae68ac0808271549p2b5802bg884e2d3f46992f3e@mail.gmail.com>

Hi guys,

On a follow-up to this, I've provided Jamis with a mingw32 gem for
sqlite3-ruby 1.2.3, so you should no longer need to build from scratch
:)

Mike

On Sat, Jul 26, 2008 at 4:11 PM, Luis Lavena <luislavena at gmail.com> wrote:
> On Sat, Jul 26, 2008 at 9:37 PM, Fabio Akita <fabioakita at gmail.com> wrote:
>> Hi, Luis I am re-copying the question I sent you here in the list.
>>
>> I've built the most current One-Click installer and it worked great. I
>> installed the devkit version and I am now trying to install the
>> sqlite3-ruby gem.
>>
>> C:\>gem install sqlite3-ruby -- --with-sqlite3-dir=c:/src/sqlite-source-3_6_0
>> Building native extensions.  This could take a while...
>> ERROR:  Error installing sqlite3-ruby:
>>        ERROR: Failed to build gem native extension.
>>
>> c:/ruby18/bin/ruby.exe extconf.rb install sqlite3-ruby --
>> --with-sqlite3-dir=c:/src/sqlite-source-3_6_0
>> checking for fdatasync() in -lrt... no
>> checking for sqlite3.h... no
>> *** extconf.rb failed ***
>> Could not create Makefile due to some reason, probably lack of
>> necessary libraries and/or headers.  Check the mkmf.log file for more
>> details.  You may need configuration options.
>>
>> ...
>>
>> I've downloaded the sqlite3 sources from:
>> http://www.sqlite.org/sqlite-source-3_6_0.zip
>>
>> Am I missing something?
>>
>
> Actually, is not 100% your fault ;-)
>
> You need the pre-built binaries besides the source code:
> http://sqlite.org/sqlitedll-3_6_0.zip
>
> Then you can grab either source or the amalgamation version, we only
> care about sqlite3.h which is inside.
>
> >From the dll package you will have the dll and a .def file. We now
> need to create the linking library that will be used by gcc to link
> against sqlite3 dll.
>
> So, until they provide a ready to use sqlite3 package:
>
> 1) create a sqlite3 folder
> 2) unzip sqlitedll-3_6_0.zip into sqlite3/lib folder
> 3) unzil from the sources the sqlite3.h file and put into sqlite3/include folder
> 3) you will need to call dlltool to create the .a library to be able
> to compile with gcc:
>
> D:\src\sqlite3\lib>c:\Ruby18\devkit\mingw\bin\dlltool.exe --dllname sqlite3.dll
> --def sqlite3.def --output-lib sqlite3.a
>
> 4) Now you can supply the --with-sqlite3-dir to gem install:
>
> gem install sqlite3-ruby -- --with-sqlite3-dir=d:/src/sqlite3
> Building native extensions.  This could take a while...
> Successfully installed sqlite3-ruby-1.2.2
> 1 gem installed
> Installing ri documentation for sqlite3-ruby-1.2.2...
> Installing RDoc documentation for sqlite3-ruby-1.2.2...
>
> Maybe we should point this in the Wiki? :-D
>
> HTH,
> --
> Luis Lavena
> AREA 17
> -
> Human beings, who are almost unique in having the ability to learn from
> the experience of others, are also remarkable for their apparent
> disinclination to do so.
> Douglas Adams
> _______________________________________________
> Rubyinstaller-devel mailing list
> Rubyinstaller-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rubyinstaller-devel
>