Mysql-ruby for ruby 1.8.1 on windows

ruby-talk
1

Does anyone ever compiled them sucessfully? Please post the binary …
thanks

2

First of all, thanks for sharing your experience with the rest of us.
Perhaps, this is what we need to get Ruby a truly platform/OS independent by
making all its (popular/necessary) apps/tools available on any platform/os.

What compiler and other tools do you use to compile them sucessfully? Will
it compile with vc6 or vc7? What are the necessary changes you have to do in
the source or Makefile? etc.etc.

Thanks again.

“Tim Sutherland” timsuth@ihug.co.nz wrote in message
news:slrnbvt8ok.7ng.timsuth@europa.zone…

[…]

I’ve “fixed” the instructions, in the sense that they make sense to me,
however the mysql.so library I build this way segfaults on me sometimes.
(But a binary I built a while ago in a similar way doesn’t seem to
segfault,
at least I can’t reproduce it.)

NB: From memory the one I built a while ago was done by using the error
messages from the linker when trying to build mysql-ruby (things like
“undefined reference `mysql_close@4’”) to generate a .def listing the
symbol
names we want to export, and then using dlltool to create a
libmysqlclient.a
using these, and then “make distclean” in mysql-ruby and rebuilding.

i.e. a process like

$ dlltool --dllname /c/mysql/lib/opt/libmySQL.dll --output-lib
/c/mysql/lib/libmysqlclient.a --def /c/mysql/include/Libmysql.def
$ ruby extconf.rb --with-mysql-dir=/c/mysql
$ make 2>errors.txt
$ cat > make_def.rb
syms =
ARGF.each_line { |line|
match = line.scan(/undefined reference `([^‘]*)’/)
syms << match[0][0] if match.size == 1
}
puts(‘EXPORTS’)
puts(syms.uniq)
^D
$ ruby make_def.rb < errors.txt > symbols.def
$ dlltool --dllname /c/mysql/lib/opt/libmySQL.dll --output-lib
/c/mysql/lib/libmysqlclient.a --def symbols.def -k
$ make distclean
$ ruby extconf.rb --with-mysql-dir=/c/mysql
$ make
$ make install

If someone could test this process and report back it would be good,
otherwise I may have time to try it on Monday afternoon or Tuesday.

This idea assumes that the libmySQL.dll functions use stdcall, but were
compiled with MSVC using a .def file which says not to use the @
decorations. gcc on the other hand always expects @ when stdcall is
used. Hence it gets confused when it tries to look for functions like
mysql_close@4 which don’t exist. (Only ‘mysql_close’ does.)

Idea: mysql/lib/mysqlclient.lib is clearly using stdcall (has @
suffixes), perhaps we could use this rather than libmySQL.dll. I will
check
this when I have access to Windows next week.

The basic issue with building the mysql library is that in the Mysql
distribution, mysql/lib/Readme says the dlls are compiled with __cdecl,
while the mysql/include header files say that everything uses __stdcall.

Possibly the Readme is wrong and they really are using __stdcall. This
could

···

In article slrnbvsctp.66r.timsuth@europa.zone, Tim Sutherland wrote:

explain the segfaults.
[…]

I disassembled libmySQL.dll and a lot of the time ‘call’ is followed by
adding a constant to %esp. This suggests it really is using cdecl.

Why would mysql.h say the functions are __stdcall and libmySQL.dll use
__cdecl?

Mini-rant: Microsoft - if you’re going to have three different calling
conventions (cdecl, stdcall, fastcall), it would be good to have something
like:
cdecl functions are prefixed with CDECL_
stdcall functions are prefixed with STDCALL_
fastcall function are prefixed with FASTCALL_

e.g.
CDECL_mysql_close
or STDCALL_mysql_close

so compilers could automatically detect the calling convention and Do The
Right Thing.