Re: sqlite3-ruby / sqlite3 3.6.23.1 / windows server 2008 build issue
Luis Lavena
> Luis,
>
Hello,
I'm bringing this conversation to both RubyInstaller and the
co-maintainer of sqlite3-ruby Aaron Patterson. In the future please
keep the conversation either on mailing lists or tickets that can be
used for future references for other with exact same questions or
issues.
> It looks like you have taken over the sqlite3-ruby gem from Jamis Buck, who
> abandoned it - or at least didn't care about it working on Windows. That is
> awesome. Unfortunately, I am having some issues with the gem. I include all of
> the technical details below.
We had an full month of beta releases of SQLite3 1.3 version:
http://rubygems.org/gems/sqlite3-ruby/versions
It is a sad thing that you got affected by the gem.
> First, it is important to note that I roll my own SQLite3. I have C apps that use
> it that predate any Ruby usage. I currently have 3.6.23.1 installed. For what
> it's worth, here's how I build it:
>
Why you need to roll your own version? Are you using custom extensions
to SQLite3? If not, then you cans safely use the existing sqlite3
binaries provided by sqlite.org and leave your C programs alone.
> cl /DSQLITE_ENABLE_COLUMN_METADATA /DNO_TCL /I. /GS /MD /LD sqlite3.c /I.
> /IC:\icu\include sqlite3.def
> cl /DNO_TCL /I. /Fesqlite3 /GS /MD shell.c sqlite3.c /I. /IC:\icu\include
>
What version of Visual C are you using?
> I place the following in the c:\sqlite3 directory:
>
> sqlite3.dll
> sqlite3.exe
> sqlite3.h
> sqlite3.lib
> sqlite3ext.h
>
> Now that I am playing around with SQLite3 in Ruby I attempt to install the
> sqlite3-ruby gem like this:
>
> gem install sqlite3-ruby -- --with-sqlite3-include=c:\sqlite3
> --with-sqlite3-lib=c:\sqlite3
>
What is your Ruby platform? (ruby -v)
Unless you specify --platform=ruby it will install the pre-built
binaries for it.
> This installs, but does not work, stating "No definition for libversion".
> However, I can see it:
>
> dumpbin /exports c:\sqlite3\sqlite3.dll | ack libversion
>
Is that DLL in the search path? do you have "where" or "which" to look
for sqlite3.dll ?
> I figure the gem is trying to roll its own SQLite3. When I try and roll the
> sqlite3-ruby gem from source, I get similar problems:
>
> git clone http://github.com/luislavena/sqlite3-ruby.git
> cd sqlite3-ruby
> ruby setup.rb config -- --with-sqlite3-include=c:\sqlite3
> --with-sqlite3-lib=c:\sqlite3
>
> This blows up. A cursory glance at ext\sqlite3\mkmf.log shows that
> sqlite3_libversion_number cannot be found, yet it is in my sqlite3.dll. Again, it
> appears that this gem is downloading and rolling its own sqlite3 even though I
> indicated that it should use the sqlite3 DLL and headers in c:\sqlite3.
>
It all depends on the lib export library that you're using. Without
knowing what are the contents of mkmf.log I can only guess, but:
1) Always use backslashes for paths in gem installation commands
(c:/sqlite3 instead of c:\sqlite3)
2) Please provide enough information of your ruby installation,
executing "gem env" can provide us enough information to be able to
reproduce the environment
3) On gem compilation issues, please provide a pastie of the
gem_make.out and mkmf.log that remains inside the gem installation
folder.
4) If you're using a compiler, please provide enough information of
it, like which version you're trying to use.
> How do I resolve this?
Please collect all the above data so we can help you better.
sqlite3-ruby binaries for Windows are generated through a process of
cross compilation, meaning the binaries are generated from Linux or
OSX using GCC. On Windows, I've used RubyInstaller and the Development
Kit.
If you don't have special needs for Visual Studio, I would recommend
you get the same environment.
Building sqlite3 from source code is not a viable solution for us, so
your case is a bit special.
Please join RubyInstaller group so we can help you out better:
http://groups.google.com/group/rubyinstaller
Looking forward to hear from you.
--
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
Luis Lavena
> Luis,
>
> Thanks for the reply. You nailed it. Here's what is interesting: up until
> this Monday I was rolling my own Ruby 1.9.1 on Windows. That's why this
> problem didn't happen before. Only when I went back to ruby-lang.org's 1.8.7
> did this happen. I will weigh the requirements and determine the course of
> action to take. Once again, thank you very much for the assistance.
Last week ruby-lang.org links changed from garbagecollect links to
RubyInstaller ones with the completion of the installers and the
launch of the new website.
RubyInstallers are signed, by me, but not ruby executables or
extensions, that could change in the future, who knows.
The garbagecollect builds are based on Visual C 6.0, something that is
old and not possible to adquire (free) for people to compile
extensions or contribute.
Since Ruby stores compiler information in its configuration files, it
worked for you because it had defined cl.exe and nmake.exe as compiler
options.
Those options do not exist in RubyInstaller, since is built with GCC (MinGW)
The newer environment and installers had improved not only performance
of Ruby, but also the ecosystem since is now, combined with the
Development Kit, install gems that do not provide binaries for
Windows, even more, create your own.
Now, thanks to complementary tools like rake-compilers, developers
using Linux or OSX are starting to provide binaries for Windows, which
also has promoted the status of Ruby for Windows a bit more. Yet a
long path needs to be walked to be considered first class citizen.
Please feel free to join RubyInstaller group and pop your questions
about the build process that is located at our repository:
http://github.com/oneclick/rubyinstaller/
Regards,