Hi all. A few musings: re: GPL versus MIT. I suppose you could have the installer actually download mingw+msys at install time, and thus you wouldn''t be distributing GPL code. Either that or the gem way. I''d be happy to help with the gem one. re: rake-compiler Does this integrate with newgem at all? Note: with rubyinstaller currently I get [when I run rake] ... mv zlib1.dll bin cd - cd sandbox/ruby_1_8 patching file `dln.c'' patching file `process.c'' patching file `array.c'' patching file `bignum.c'' patching file `eval.c'' patching file `intern.h'' patching file `io.c'' patching file `lib/webrick/httpservlet/filehandler.rb'' Hunk #1 FAILED at 163. Hunk #2 succeeded at 232 with fuzz 2 (offset 33 lines). Hunk #3 FAILED at 306. Hunk #4 FAILED at 360. 3 out of 4 hunks FAILED -- saving rejects to lib/webrick/httpservlet/filehandler.rb.rej patching file `sprintf.c'' patching file `string.c'' rake aborted! is this expected? Thanks. -=r
On Wed, Jan 21, 2009 at 8:33 PM, Roger Pack <rogerpack2005 at gmail.com> wrote:> Hi all. > > A few musings: > > re: GPL versus MIT. I suppose you could have the installer actually > download mingw+msys at install time, and thus you wouldn''t be > distributing GPL code. Either that or the gem way. I''d be happy to > help with the gem one. >the devkit gem will take the recipes from rubyinstaller and download the gcc+msys, put the proper batch files into ruby bindir and it''s done ;-)> re: rake-compiler > Does this integrate with newgem at all?newgem? DrNic package? is not using nothing like that, own baked recipes. The idea of rake-compiler reduce the need for me to tackle projects and provide Windows gems. I thought will be much better option and more sustainable in the long run. It also will play nice with some things I''m playing with, like building One-Click Installer almost fully from Linux.> Note: > with rubyinstaller currently I get [when I run rake] > > ... > mv zlib1.dll bin > cd - > cd sandbox/ruby_1_8 > patching file `dln.c'' > patching file `process.c'' > patching file `array.c'' > patching file `bignum.c'' > patching file `eval.c'' > patching file `intern.h'' > patching file `io.c'' > patching file `lib/webrick/httpservlet/filehandler.rb'' > Hunk #1 FAILED at 163. > Hunk #2 succeeded at 232 with fuzz 2 (offset 33 lines). > Hunk #3 FAILED at 306. > Hunk #4 FAILED at 360. > 3 out of 4 hunks FAILED -- saving rejects to > lib/webrick/httpservlet/filehandler.rb.rej > patching file `sprintf.c'' > patching file `string.c'' > rake aborted! > > is this expected? >maybe there is something during patch, which version is trying to patch? p114? p287?> Thanks. > -=rThanks to you for the feedback -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exup?ry
> The idea of rake-compiler reduce the need for me to tackle projects > and provide Windows gems. I thought will be much better option and > more sustainable in the long run. > > It also will play nice with some things I''m playing with, like > building One-Click Installer almost fully from Linux.Nice :) I suppose one thing people could do [if it were possible] is specify a windows dependency of the devkit gem if they don''t want to have to compile it themselves [and if it works].>> is this expected? >> > > maybe there is something during patch, which version is trying to > patch? p114? p287?This was with straight git clone then rake--I assume that''s 114? I am wondering if it would be possible to publish "alpha" releases, like mingw OCI 1.8.7, 1.9.1 preview2, etc. Just mark them as alpha and warn people about them. Thoughts? -=r
On Sat, Jan 24, 2009 at 7:13 PM, Roger Pack <rogerpack2005 at gmail.com> wrote:>> The idea of rake-compiler reduce the need for me to tackle projects >> and provide Windows gems. I thought will be much better option and >> more sustainable in the long run. >> >> It also will play nice with some things I''m playing with, like >> building One-Click Installer almost fully from Linux. > > Nice :) > I suppose one thing people could do [if it were possible] is specify a > windows dependency of the devkit gem if they don''t want to have to > compile it themselves [and if it works]. >Please apologize but I fully don''t understand your statement. Can you rephrase it?>>> is this expected? >>> >> >> maybe there is something during patch, which version is trying to >> patch? p114? p287? > > This was with straight git clone then rake--I assume that''s 114? >Yes, p114 was the altest one, but the way it applies the patches was not perfect.> > I am wondering if it would be possible to publish "alpha" releases, > like mingw OCI 1.8.7, 1.9.1 preview2, etc. > Just mark them as alpha and warn people about them. > Thoughts? > -=rNeither 1.8.7 or 1.9.1-preview2 builds properly for me (native or cross-compiling). Opened some tickets that got addressed. I have no interest in 1.8.7, honestly. 1.8.6 and newer patchelevels will be my target for 1.8.x The other time will be 1.9.x Problem with 1.9 is that I cannot use the same recipes to build both, there are several changes that need to be manually handled right now. -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exup?ry
>> I suppose one thing people could do [if it were possible] is specify a >> windows dependency of the devkit gem if they don''t want to have to >> compile it themselves [and if it works]. >> > > Please apologize but I fully don''t understand your statement. Can you > rephrase it?I was thinking out loud that for gems that compile out of the box in a mingw environment, they could add a dependency to the devkit gem [then the author''s wouldn''t have to worry about cross compiling their own binary extensions--i.e. it would be a useful gem for authors]. re: trouble compiling I have had trouble building them, too. Typically I have had success building them if I use the daily snapshot or the 187p72.tar.gz download. I haven''t tried the preview releases. It is too bad that trunk requires autoconf version > 1.60, so am forced to use the snapshots [ugh]. Not that I want 187 more than 186 at all. Unless the MBARI patches make their way to 187 only and not 186, then I would prefer the former. A question: with 187p72 build I get 01/21/2009 04:41 PM 17,290,874 libmsvcrt-ruby18-static.a which is a rather large file--I''d guess that''s expected? [and with 1.9 it''s something like 30MB]. ? Thanks! -=r
Hi,> A question: > > with 187p72 build I get > 01/21/2009 04:41 PM 17,290,874 libmsvcrt-ruby18-static.a > which is a rather large file--I''d guess that''s expected? [and with 1.9 > it''s something like 30MB]. > ?I just spent the last few days fiddling with Ruby compilation on Windows, and these are the latest numbers I get with compiling the latest versions of Ruby found in the SVN repositories: A) Built with MinGW and GCC 4, including openssl, iconv, zlib, readline: C:\>dir C:\opt\mingw_ruby-1.8.6\lib\libmsvcrt-ruby18-static.a 25/01/2009 23:59 2.594.308 libmsvcrt-ruby18-static.a C:\>dir C:\opt\mingw_ruby-1.8.7\lib\libmsvcrt-ruby18-static.a 26/01/2009 00:20 2.735.214 libmsvcrt-ruby18-static.a C:\>dir C:\opt\mingw_ruby-1.9.1\lib\libmsvcrt-ruby191-static.a 26/01/2009 00:33 5.097.338 libmsvcrt-ruby191-static.a C:\>dir C:\opt\mingw_ruby-1.9.2\lib\libmsvcrt-ruby191-static.a 26/01/2009 01:00 5.131.112 libmsvcrt-ruby191-static.a B) Built with VS C++ 2008, including openssl, iconv, zlib (no readline): C:\>dir C:\opt\ruby-1.8.6\lib\msvcr90-ruby18-static.lib 26/01/2009 16:20 2.155.482 msvcr90-ruby18-static.lib C:\>dir C:\opt\ruby-1.8.7\lib\msvcr90-ruby18-static.lib 26/01/2009 16:47 2.155.482 msvcr90-ruby18-static.lib That''s just for comparison purposes, I''d guess. :-) To install my MinGW environment I followed the instructions found at http://www.mingw.org/wiki/HOWTO_Install_the_MinGW_GCC_Compiler_Suite I use MSYS which has a HOWTO tutorial linked to from the MinGW one. Plus, I downloaded any missing binaries from http://gnuwin32.sourceforge.net/ The files I installed include: C:\>dir safe_or_not\programming\mingw 29/11/2008 04:29 8.944.043 binutils-2.19-mingw32-rc1-bin.tar.gz 29/11/2008 04:32 54.186.135 gcc-4.3.0-20080502-mingw32-alpha-bin.7z 29/11/2008 04:22 6.677.497 gcc-part-c++-4.3.0-20080502-2-mingw32-alpha-bin.tar.gz 29/11/2008 04:22 8.077.458 gcc-part-core-4.3.0-20080502-2-mingw32-alpha-bin.tar.gz 29/11/2008 04:28 560.294 mingwrt-3.15.1-mingw32.tar.gz 29/11/2008 04:30 1.643.172 w32api-3.12-mingw32-dev.tar.gz C:\>dir safe_or_not\programming\mingw\msys 29/11/2008 06:50 1.195.259 autoconf-2.63.tar.bz2 29/11/2008 06:50 936.322 automake-1.10.2.tar.bz2 29/11/2008 06:09 543.655 bash-3.1-MSYS-1.0.11-1.tar.bz2 29/11/2008 06:12 832.147 coreutils-5.97-MSYS-1.0.11-snapshot.tar.bz2 29/11/2008 06:51 13.137.920 libtool-2.2.6a.tar.gz 29/11/2008 06:13 89.315 lzma-4.43-MSYS-1.0.11-1-bin.tar.gz 29/11/2008 06:56 134.927 m4-1.4.7-MSYS.tar.bz2 29/11/2008 05:24 2.808.061 MSYS-1.0.10.exe 29/11/2008 05:44 1.935.914 msysCORE-1.0.11-2007.01.19-1.tar.bz2 29/11/2008 05:38 10.299.560 msysDTK-1.0.1.exe C:\>dir safe_or_not\programming\mingw\gnuwin32 30/11/2008 00:20 585.372 bison-2.1-bin.zip 30/11/2008 01:26 708.206 bison-2.1-dep.zip 01/12/2008 02:47 49.414 byacc-1.9-1-bin.zip 30/11/2008 02:24 262.813 sed-4.1.5-bin.zip 30/11/2008 02:24 708.206 sed-4.1.5-dep.zip C:\>dir safe_or_not\pogramming\mingw\gnuwin32\libs 25/01/2009 13:56 25.917 crypt-2.2.5-bin.zip 25/01/2009 01:48 19.846 crypt-2.2.5-lib.zip 25/01/2009 21:51 828.380 libiconv-1.9.2-1-bin.zip 25/01/2009 21:50 50.981 libiconv-1.9.2-1-dep.zip 25/01/2009 21:51 731.496 libiconv-1.9.2-1-lib.zip 14/01/2009 12:03 5.906.403 openssl-0.9.8h-1-bin.zip 14/01/2009 12:02 1.287.741 openssl-0.9.8h-1-lib.zip 14/01/2009 12:00 443.791 readline-5.0-1-bin.zip 14/01/2009 12:01 233.419 readline-5.0-1-lib.zip 25/01/2009 13:34 99.777 zlib-1.2.3-bin.zip 25/01/2009 01:20 71.569 zlib-1.2.3-lib.zip Some of the library files I share between VS C++ 2008 and MinGW, but the MinGW ones I tend to copy to the c:\mingw directory, in order for libs, headers to be easily found. MSYS includes the "sed" command already so skip installing it for MinGW, otherwise it can result in an error of conflict. But "sed" might be needed for VS C++ 2008 compilation, alongside Bison or YACC depending on the Ruby version (1.8, 1.9). You might need to copy yacc to byacc to make the Ruby building routines to find it. For compiling with VS C++ 2008 you don''t need "autoconf" tools. The problem with VS C++ is getting the "readline" extension built, because I don''t think it''s supported. If anyone knows what to do to get it built, I am all ears. :-) At times you might need to rename a library file like libiconv.lib to iconv.lib for the extension setup to detect it, when using VS C++. I got my openssl for VS C++ from http://www.slproweb.com/products/Win32OpenSSL.html And had to edit one of its files to make a conflicting error with VS C++ to go away: http://rt.openssl.org/Ticket/Display.html?id=1700&user=guest&pass=guest Finally, for the openssl, zlib, iconv, readline libraries to work, you might need to copy them to Ruby''s bin dir: C:\>dir \opt\ruby-1.8.6\bin\*.dll 07/01/2009 18:27 1.016.832 libeay32.dll 14/10/2004 00:08 978.432 libiconv2.dll 09/10/2004 18:25 101.888 libintl3.dll 03/09/2008 22:49 232.960 libssl32.dll 26/01/2009 16:23 707.072 msvcr90-ruby18.dll 07/01/2009 18:27 200.192 ssleay32.dll 20/07/2005 18:05 75.264 zlib1.dll I am not 100% sure about which of those DLL files I could safely remove from the Ruby bin dir, though. :-) There might be some excess there, I mean. To test which libraries are loading after building a Ruby version, I use the simple: PS C:\> C:\opt\ruby-1.8.6\bin\ruby.exe -v -rzlib -riconv -ropenssl -e "p 5" ruby 1.8.6 (2009-01-26 patchlevel 310) [i386-mswin32_90] 5 So no apparent errors there, huh? Why am I doing this? I figure this could help with motivating other folks when they get stuck building Ruby on Windows. :-) I wish I could make all of that more automatic, but it''s tough business. Cheers, Joao
>> with 187p72 build I get >> 01/21/2009 04:41 PM 17,290,874 libmsvcrt-ruby18-static.a >> which is a rather large file--I''d guess that''s expected? [and with 1.9 >> it''s something like 30MB]. >> ? > > I just spent the last few days fiddling with Ruby compilation on Windows, > and these are the latest numbers I get with compiling the latest versions > of Ruby found in the SVN repositories: > > A) Built with MinGW and GCC 4, including openssl, iconv, zlib, readline: > > C:\>dir C:\opt\mingw_ruby-1.8.6\lib\libmsvcrt-ruby18-static.a > 25/01/2009 23:59 2.594.308 libmsvcrt-ruby18-static.aWow those are far smaller than mine--I wonder why? I am using GCC 3 maybe that''s it. Have you tried the rubyinstaller scripts? What size are they? Take care. -=r
On Mon, Jan 26, 2009 at 3:42 PM, Roger Pack <rogerpack2005 at gmail.com> wrote:>>> I suppose one thing people could do [if it were possible] is specify a >>> windows dependency of the devkit gem if they don''t want to have to >>> compile it themselves [and if it works]. >>> >> >> Please apologize but I fully don''t understand your statement. Can you >> rephrase it? > > I was thinking out loud that for gems that compile out of the box in a > mingw environment, they could add a dependency to the devkit gem [then > the author''s wouldn''t have to worry about cross compiling their own > binary extensions--i.e. it would be a useful gem for authors]. > > re: trouble compiling > > I have had trouble building them, too. > > Typically I have had success building them if I use the daily snapshot > or the 187p72.tar.gz download. I haven''t tried the preview releases. > It is too bad that trunk requires autoconf version > 1.60, so am > forced to use the snapshots [ugh]. > > Not that I want 187 more than 186 at all. Unless the MBARI patches > make their way to 187 only and not 186, then I would prefer the > former. >Again, no 1.8.7 from the official One-Click side. If you want to shoot your feet, go ahead and use the recipes :-)> A question: > > with 187p72 build I get > 01/21/2009 04:41 PM 17,290,874 libmsvcrt-ruby18-static.a > which is a rather large file--I''d guess that''s expected? [and with 1.9 > it''s something like 30MB]. > ?The library is ''as-is'' without stripping debug symbols or anything.> > Thanks! > > -=r > _______________________________________________ > Rubyinstaller-devel mailing list > Rubyinstaller-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubyinstaller-devel >-- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exup?ry
On Mon, Jan 26, 2009 at 6:40 PM, Joao Pedrosa <joaopedrosa at gmail.com> wrote:> Hi, > >> A question: >> >> with 187p72 build I get >> 01/21/2009 04:41 PM 17,290,874 libmsvcrt-ruby18-static.a >> which is a rather large file--I''d guess that''s expected? [and with 1.9 >> it''s something like 30MB]. >> ? > > I just spent the last few days fiddling with Ruby compilation on Windows, > and these are the latest numbers I get with compiling the latest versions > of Ruby found in the SVN repositories: > > A) Built with MinGW and GCC 4, including openssl, iconv, zlib, readline: > > C:\>dir C:\opt\mingw_ruby-1.8.6\lib\libmsvcrt-ruby18-static.a > 25/01/2009 23:59 2.594.308 libmsvcrt-ruby18-static.a > > C:\>dir C:\opt\mingw_ruby-1.8.7\lib\libmsvcrt-ruby18-static.a > 26/01/2009 00:20 2.735.214 libmsvcrt-ruby18-static.a > > C:\>dir C:\opt\mingw_ruby-1.9.1\lib\libmsvcrt-ruby191-static.a > 26/01/2009 00:33 5.097.338 libmsvcrt-ruby191-static.a > > C:\>dir C:\opt\mingw_ruby-1.9.2\lib\libmsvcrt-ruby191-static.a > 26/01/2009 01:00 5.131.112 libmsvcrt-ruby191-static.a > > B) Built with VS C++ 2008, including openssl, iconv, zlib (no readline): > > C:\>dir C:\opt\ruby-1.8.6\lib\msvcr90-ruby18-static.lib > 26/01/2009 16:20 2.155.482 msvcr90-ruby18-static.lib > > C:\>dir C:\opt\ruby-1.8.7\lib\msvcr90-ruby18-static.lib > 26/01/2009 16:47 2.155.482 msvcr90-ruby18-static.lib > > > That''s just for comparison purposes, I''d guess. :-) > > To install my MinGW environment I followed the instructions found at > http://www.mingw.org/wiki/HOWTO_Install_the_MinGW_GCC_Compiler_Suite > > I use MSYS which has a HOWTO tutorial linked to from the MinGW one. > > Plus, I downloaded any missing binaries from http://gnuwin32.sourceforge.net/ >Woot, you took the long road... why didn''t played with the mingw recipes? The size of the static library is not a isse, you can still do strip of the symbol and get a smaller version.> The files I installed include: > > C:\>dir safe_or_not\programming\mingw > > 29/11/2008 04:29 8.944.043 binutils-2.19-mingw32-rc1-bin.tar.gz > 29/11/2008 04:32 54.186.135 gcc-4.3.0-20080502-mingw32-alpha-bin.7z > 29/11/2008 04:22 6.677.497 > gcc-part-c++-4.3.0-20080502-2-mingw32-alpha-bin.tar.gz > 29/11/2008 04:22 8.077.458 > gcc-part-core-4.3.0-20080502-2-mingw32-alpha-bin.tar.gz > 29/11/2008 04:28 560.294 mingwrt-3.15.1-mingw32.tar.gz > 29/11/2008 04:30 1.643.172 w32api-3.12-mingw32-dev.tar.gz > > C:\>dir safe_or_not\programming\mingw\msys > > 29/11/2008 06:50 1.195.259 autoconf-2.63.tar.bz2 > 29/11/2008 06:50 936.322 automake-1.10.2.tar.bz2 > 29/11/2008 06:09 543.655 bash-3.1-MSYS-1.0.11-1.tar.bz2 > 29/11/2008 06:12 832.147 coreutils-5.97-MSYS-1.0.11-snapshot.tar.bz2 > 29/11/2008 06:51 13.137.920 libtool-2.2.6a.tar.gz > 29/11/2008 06:13 89.315 lzma-4.43-MSYS-1.0.11-1-bin.tar.gz > 29/11/2008 06:56 134.927 m4-1.4.7-MSYS.tar.bz2 > 29/11/2008 05:24 2.808.061 MSYS-1.0.10.exe > 29/11/2008 05:44 1.935.914 msysCORE-1.0.11-2007.01.19-1.tar.bz2 > 29/11/2008 05:38 10.299.560 msysDTK-1.0.1.exe > > C:\>dir safe_or_not\programming\mingw\gnuwin32 > > 30/11/2008 00:20 585.372 bison-2.1-bin.zip > 30/11/2008 01:26 708.206 bison-2.1-dep.zip > 01/12/2008 02:47 49.414 byacc-1.9-1-bin.zip > 30/11/2008 02:24 262.813 sed-4.1.5-bin.zip > 30/11/2008 02:24 708.206 sed-4.1.5-dep.zip > > C:\>dir safe_or_not\pogramming\mingw\gnuwin32\libs > > 25/01/2009 13:56 25.917 crypt-2.2.5-bin.zip > 25/01/2009 01:48 19.846 crypt-2.2.5-lib.zip > 25/01/2009 21:51 828.380 libiconv-1.9.2-1-bin.zip > 25/01/2009 21:50 50.981 libiconv-1.9.2-1-dep.zip > 25/01/2009 21:51 731.496 libiconv-1.9.2-1-lib.zip > 14/01/2009 12:03 5.906.403 openssl-0.9.8h-1-bin.zip > 14/01/2009 12:02 1.287.741 openssl-0.9.8h-1-lib.zip > 14/01/2009 12:00 443.791 readline-5.0-1-bin.zip > 14/01/2009 12:01 233.419 readline-5.0-1-lib.zip > 25/01/2009 13:34 99.777 zlib-1.2.3-bin.zip > 25/01/2009 01:20 71.569 zlib-1.2.3-lib.zip > > > Some of the library files I share between VS C++ 2008 and MinGW, > but the MinGW ones I tend to copy to the c:\mingw directory, in > order for libs, headers to be easily found. MSYS includes the > "sed" command already so skip installing it for MinGW, otherwise > it can result in an error of conflict. > > But "sed" might be needed for VS C++ 2008 compilation, alongside > Bison or YACC depending on the Ruby version (1.8, 1.9). You might > need to copy yacc to byacc to make the Ruby building routines to > find it. For compiling with VS C++ 2008 you don''t need "autoconf" tools. > > The problem with VS C++ is getting the "readline" extension built, because > I don''t think it''s supported. If anyone knows what to do to get it built, I am > all ears. :-) > > At times you might need to rename a library file like libiconv.lib to iconv.lib > for the extension setup to detect it, when using VS C++. > > I got my openssl for VS C++ from > http://www.slproweb.com/products/Win32OpenSSL.html > > And had to edit one of its files to make a conflicting error with VS > C++ to go away: > http://rt.openssl.org/Ticket/Display.html?id=1700&user=guest&pass=guest > > Finally, for the openssl, zlib, iconv, readline libraries to work, you > might need > to copy them to Ruby''s bin dir: > > C:\>dir \opt\ruby-1.8.6\bin\*.dll > > 07/01/2009 18:27 1.016.832 libeay32.dll > 14/10/2004 00:08 978.432 libiconv2.dll > 09/10/2004 18:25 101.888 libintl3.dll > 03/09/2008 22:49 232.960 libssl32.dll > 26/01/2009 16:23 707.072 msvcr90-ruby18.dll > 07/01/2009 18:27 200.192 ssleay32.dll > 20/07/2005 18:05 75.264 zlib1.dll > > I am not 100% sure about which of those DLL files > I could safely remove from the Ruby bin dir, though. :-) There > might be some excess there, I mean. > > To test which libraries are loading after building a Ruby version, > I use the simple: > > PS C:\> C:\opt\ruby-1.8.6\bin\ruby.exe -v -rzlib -riconv -ropenssl -e "p 5" > ruby 1.8.6 (2009-01-26 patchlevel 310) [i386-mswin32_90] > 5 > > So no apparent errors there, huh? > > Why am I doing this? I figure this could help with motivating other folks > when they get stuck building Ruby on Windows. :-)Thanks for sharing all your experience on this. One point to take in consideration is that using binaries from gnuwin32 project they link to MSVCRT.dll while your Ruby built with VC9 links to MSVCR90, two different CRT that can really compromise the stability of the interpreter in memory allocation and freeing processes. http://blog.mmediasys.com/2008/01/17/ruby-for-windows-part-1/ And also my other post in the list: http://rubyforge.org/pipermail/rubyinstaller-devel/2008-January/000230.html> I wish I could make all of that more automatic, but it''s tough business. >RubyInstaller recipes for MinGW?: http://github.com/luislavena/rubyinstaller/tree/master> Cheers, > JoaoRegards, -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exup?ry