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

In article <bthkt6$7eq5q$1>, Useko Netsumi wrote:
>Does anyone ever compiled them sucessfully? Please post the binary ...
>thanks

Yes, I have done compiled this. I'll upload instructions/libs tomorrow in
about 15 hours when I'm at work.

From memory I had to use some utilities on the mysql client library to
change the calling convention. I could then compile mysql-ruby with
msys/mingw.

In article <slrnbvq4k3.3c2.timsuth>, Tim Sutherland wrote:
>In article <bthkt6$7eq5q$1>, Useko Netsumi wrote:
>>Does anyone ever compiled them sucessfully? Please post the binary ...
>>thanks
>
>Yes, I have done compiled this. I'll upload instructions/libs tomorrow in
>about 15 hours when I'm at work.
[...]

I have put instructions at
http://rubydotnetproxy.rubyforge.org/mysql_win.html

Hope this helps.

In article <slrnbvs5t1.5t5.timsuth>, Tim Sutherland wrote:
>In article <slrnbvq4k3.3c2.timsuth>, Tim Sutherland wrote:
>>In article <bthkt6$7eq5q$1>, Useko Netsumi wrote:
>>>Does anyone ever compiled them sucessfully? Please post the binary ...
>>>thanks
>>
>>Yes, I have done compiled this. I'll upload instructions/libs tomorrow in
>>about 15 hours when I'm at work.
>[...]
>
>I have put instructions at
> [..]

Oops, my instructions are completely wrong! Don't use them yet...

In article <slrnbvs96n.630.timsuth>, Tim Sutherland wrote:
>In article <slrnbvs5t1.5t5.timsuth>, Tim Sutherland wrote:
>>In article <slrnbvq4k3.3c2.timsuth>, Tim Sutherland wrote:
>>>In article <bthkt6$7eq5q$1>, Useko Netsumi wrote:
>>>>Does anyone ever compiled them sucessfully? Please post the binary ...
>>>>thanks
>>>
>>>Yes, I have done compiled this. I'll upload instructions/libs tomorrow in
>>>about 15 hours when I'm at work.
>>[...]
>>
>>I have put instructions at
>> [..]
>
>Oops, my instructions are completely wrong! Don't use them yet...

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.)

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
explain the segfaults.

In article <slrnbvsctp.66r.timsuth>, Tim Sutherland wrote:
[...]
>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 @<n>
decorations. gcc on the other hand always expects @<n> 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 @<n>
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
>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.

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> wrote in message
news:suth
> In article <slrnbvsctp.66r.timsuth>, Tim Sutherland wrote:
> [...]
> >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
[..]

In article <btnsra$9iufi$1>, Useko Netsumi wrote:
>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.

I'm using msys/mingw. (Which I also used to compile Ruby.) This uses the
gcc compiler.

http://rubydotnetproxy.rubyforge.org/mysql_win.html has updated
instructions which should work.

Someone I've been conversing with off-list confirms that this
works for them.

Compiling with MSVC should be easier than with gcc, since the problems I
encountered were caused by the differences between MSVC and gcc when it
comes to cdecl/stdcall function naming. (MSVC can create stdcall functions
without the @<n> naming while gcc doesn't like this.)

If you're using MSVC then the straightforward
ruby extconf.rb --with-mysq-dir=c:/mysql
make
make install
should work.

NB: The standard mysql C client library (as used by mysql-ruby) has what
some people consider a license problem - it is under the GPL (rather than
LGPL.) Hence if you use the mysql-ruby library in your Ruby code, you must
follow the GPL. This might mean, e.g. if you distribute your program to
other people you may need to make the source available to them as well.

There is a library ruby-mysql (rather than mysql-ruby) which is written
completely in Ruby. This is under Ruby's license. This appears to implement
almost the same interface as mysql-ruby, so it shouldn't be too hard to make
it work with DBD/Mysql.rb. (Not that I'm volunteering :)