SQLite3 Compilation issue

Hey guys,

I wonder if you could help me out with this,

The situation is:
Compiled Ruby 1.8.6 myself using MSVC8
Downloaded SQLite3 and placed the headers and libraries in the
proper locations (atleast i think so)
Ran the sqlite3-ruby gem and it’s happy, everything seems fine
Testing creating a DB in irb causes it to throw up a MSCVRT8-
ruby18.dll missing error.
Recompiled ruby, but the compilation process only creates MSCVR8-
ruby18.dll (missing T)
If anyone has an idea to fix this, great! please tell me how.

So, i think, maybe its SQLite3-ruby at fault, so i’ll recompile it.
Download the sources, create a sqlite3.lib
Download the sqlite3-ruby sources, and try compiling it using my
compiler
Nags on
BLOB already defined in (something)_types.h, basically i think its
related to winsock2.h

Anyone dealt with this before?

On Mar 18, 12:27 am, mt [email protected] wrote:

Hey guys,

I wonder if you could help me out with this,

The situation is:
Compiled Ruby 1.8.6 myself using MSVC8
Downloaded SQLite3 and placed the headers and libraries in the
proper locations (atleast i think so)

Did you set INCLUDE and LIB to add these files? or you just drop them
into INCLUDE and LIB of your compiler?

Ran the sqlite3-ruby gem and it’s happy, everything seems fine
Testing creating a DB in irb causes it to throw up a MSCVRT8-
ruby18.dll missing error.

It seems you’re trying to use the pre-built windows gem instead of
compile from source… If you had RubyGems 1.0.1 installed, that
should happen :slight_smile:

the pre-built SQlite gem is built with VC6 and linked to standard ruby
runtime (MSVCRT-RUBY18.DLL)

related to winsock2.h

I’ve already reported this problem:

http://rubyforge.org/tracker/index.php?func=detail&aid=10761&group_id=254&atid=1045

Anyone dealt with this before?

Yes, been there, done that, failed too :slight_smile:

You will require to build everything from scratch for make Ruby VC8
build to work properly. That includes sqlite3 DLL itself, since it
links to a different runtime than your Ruby interpreter. Search the
list for MSVCRT VC6 and VC8 issues.

HTH,

On Wed, Mar 19, 2008 at 3:59 AM, Luis L. [email protected]
wrote:

Did you set INCLUDE and LIB to add these files? or you just drop them
into INCLUDE and LIB of your compiler?

Dropped them into the include and lib.

runtime (MSVCRT-RUBY18.DLL)

BLOB already defined in (something)_types.h, basically i think its

You will require to build everything from scratch for make Ruby VC8
build to work properly. That includes sqlite3 DLL itself, since it
links to a different runtime than your Ruby interpreter. Search the
list for MSVCRT VC6 and VC8 issues.

Sorry, I don’t understand. I did build everything from scratch, and
the last BLOB error was occuring whilst i was trying to create
Sqlite3-ruby, where sqlite3.lib had been compiled by myself on my
compiler. It just seems to me a sort of precedence issue, that if
somehow, we could exclude certain libraries from the compilation
process, we’d be fine…

Regards,
MT

On Mar 19, 2:26 am, mutahhir hayat [email protected] wrote:

Testing creating a DB in irb causes it to throw up a MSCVRT8-
ruby18.dll (missing T)
I’ve already reported this problem:
list for MSVCRT VC6 and VC8 issues.

Sorry, I don’t understand. I did build everything from scratch, and
the last BLOB error was occuring whilst i was trying to create
Sqlite3-ruby, where sqlite3.lib had been compiled by myself on my
compiler.

The BLOB error I reported in the rubyforge ticket is the same, the
SWIG generated wrapper (the .c file used in sqlite3-ruby) clash with
the BLOBL definition one of the Windows headres includes. this happens
with VC6 and VC7 too.

Regarding the compilation of sqlite3, I commented that since use the
standard distribution available online is linked with MSVCRT.dll, and
that could generate some crashes since your ruby interpreter is linked
to MSVCR80.DLL

It just seems to me a sort of precedence issue, that if
somehow, we could exclude certain libraries from the compilation
process, we’d be fine…

The problem recides in the SWIG code (.i) which is used to generate
the .c file that is raising the compilation issues.

Thanks a lot. :slight_smile:

I wish you had better news, but atleast i can abandon this, and move
back to my MINGW compiled ruby.

Mt.