Re: mysql-ruby for ruby 1.8.1 on windows ...

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" <[e-mail]> wrote in message
news:[e-mail]...
> In article <[e-mail]>, 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.