MySQL gem on 64-bit Solaris won't compile

Ruby
1

Hi all,

Solaris 10 x86 on a 64-bit Xenon server… Can anyone guess where this
is going?

root@hostname:~# gem install mysql –
–with-mysql-config=/usr/local/mysql/bin/mysql_config
Building native extensions. This could take a while…
ERROR: Error installing mysql:
ERROR: Failed to build gem native extension.

/usr/local/bin/ruby extconf.rb install mysql –
–with-mysql-config=/usr/local/mysql/bin/mysql_config
checking for mysql_ssl_set()… no
checking for mysql.h… yes
creating Makefile

make
gcc -I. -I. -I/usr/local/lib/ruby/1.8/i386-solaris2.10 -I.
-DHAVE_MYSQL_H -I/usr/local/include -I/usr/X11R6/include
-I/usr/local/ssl/include -I/usr/local/include/ncurses
-I/usr/local/BerkeleyDB.4.2/include -I/usr/openwin/include
-I/usr/local/mysql/include -m64 -mtune=k8 -fPIC -O2 -fpic -c mysql.c

gcc -shared -fPIC -L/usr/local/lib -R/usr/local/lib -R/usr/lib
-L/usr/lib -R/usr/openwin/lib -L/usr/openwin/lib -L/usr/local/ssl/lib
-R/usr/local/ssl/lib -L/usr/local/BerkeleyDB.4.2/lib
-R/usr/local/BerkeleyDB.4.2/lib -L/usr/X11R6/lib -R/usr/X11R6/lib
-L’/usr/local/lib’ -Wl,-R’/usr/local/lib’ -o mysql.so mysql.o -m64 -O2
-mtune=k8 -static-libgcc -L/usr/local/mysql/lib -lmysqlclient -lz
-lposix4 -lresolv -lgen -lsocket -lnsl -lm -ldl -lcrypt -lm -lc
ld: fatal: file /usr/lib/libcrypt.so: wrong ELF class: ELFCLASS32
ld: fatal: File processing errors. No output written to mysql.so
collect2: ld returned 1 exit status
*** Error code 1
make: Fatal error: Command failed for target `mysql.so’

Gem files will remain installed in
/usr/local/lib/ruby/gems/1.8/gems/mysql-2.7 for inspection.
Results logged to
/usr/local/lib/ruby/gems/1.8/gems/mysql-2.7/gem_make.out
root@hostname:~#

Of course make is barfing on my 32 bit libcrypt…

root@hostname:~# file /usr/lib/libcrypt.so
/usr/lib/libcrypt.so: ELF 32-bit LSB dynamic lib 80386 Version 1,
dynamically linked, not stripped, no debugging information available

root@hostname:~# file
/usr/local/lib/ruby/gems/1.8/gems/mysql-2.7/mysql.o
/usr/local/lib/ruby/gems/1.8/gems/mysql-2.7/mysql.o: ELF 64-bit LSB
relocatable AMD64 Version 1

root@hostname:~# file /usr/local/mysql/lib/libmysqlclient.so
/usr/local/mysql/lib/libmysqlclient.so: ELF 64-bit LSB dynamic lib AMD64
Version 1, dynamically linked, not stripped, no debugging information
available

I am assuming all this is happening because the Solaris package of MySQL
that I installed (from mysql.com) is a 64 bit package…

Short of reinstalling MySQL as a 32 bit app, (which I would prefer not
to do) can anyone make any suggestions? I started trying to recompile
all kinds of so everything would match and got into a cycle of one thing
depending on something else, depending on something until I broke ruby,
gem, and half the system.

Thanks in advance,
Andrew

2

Hi, I’m new to this group, but is it possible to put some sort of header
on the subject line, etc. that denotes this as a [ruby-talk] group, so
that I can set my e-mail up to automatically file these discussions
under a Ruby folder? It is difficult to sort out these e-mails from
SPAM. Or if someone else has a method of doing this on Thunderbird,
that would be much appreciated.

Thanks,

Andrew O. wrote:

-I/usr/local/BerkeleyDB.4.2/include -I/usr/openwin/include
ld: fatal: File processing errors. No output written to mysql.so

all kinds of so everything would match and got into a cycle of one thing
depending on something else, depending on something until I broke ruby,
gem, and half the system.

Thanks in advance,
Andrew

–
Stephen D.
President/CEO
Virtual DSP Corporation
4119 125th St SE
Everett, WA 98208
Tel 425.379.8888
Fax 425.357.0567
http://www.virtual-dsp.com

3

Quoth Steve D.:

Hi, I’m new to this group, but is it possible to put some sort of header
on the subject line, etc. that denotes this as a [ruby-talk] group, so
that I can set my e-mail up to automatically file these discussions
under a Ruby folder? It is difficult to sort out these e-mails from
SPAM. Or if someone else has a method of doing this on Thunderbird,
that would be much appreciated.

You can filter by the To field of the mails. All mailing list stuff
ought to
be To: “ruby-talk ML” [email protected]. There are other headers
you
could filter on:

No, we won’t be adding [ruby-talk] to the subject, this has been
discussed
before and you can learn more in the archives.

HTH,

4

Solaris 10 x86 on a 64-bit Xenon server… Can anyone guess where this
is going?

It’s Xeon. Every time you say Xenon an Intel marketing team member
kills himself. Hm… carry on.

*** Error code 1
make: Fatal error: Command failed for target `mysql.so’

Of course make is barfing on my 32 bit libcrypt…

root@hostname:~# file /usr/lib/libcrypt.so
/usr/lib/libcrypt.so: ELF 32-bit LSB dynamic lib 80386 Version 1,
dynamically linked, not stripped, no debugging information available

This looks like a Solaris bug:

http://bugs.opensolaris.org/view_bug.do?bug_id=6531439

If the workaround described there doesn’t work you might try getting the
mysql extension tarball and messing about with extconf (maybe
–with-mysql-lib=/usr/lib/amd64? ugh) and/or the Makefile.

You might also try strace/dtrace to see where the linker’s looking for
the library first, in case that workaround is incomplete.

5

You’re mixing 32-bit and 64-bit libraries.

Maybe Ruby is a 32-bit program and mysql.so is a 64-bit shared object.

6

Gerardo S. Gómez Garrido wrote:

You’re mixing 32-bit and 64-bit libraries.

Maybe Ruby is a 32-bit program and mysql.so is a 64-bit shared object.

Well, yes, apparently this is true.

My MySQL installation is 64 bit, and so as a result so are its
libraries.

andrewo@host:/opt/mysql/mysql/lib> file libmysqlclient.so
libmysqlclient.so: ELF 64-bit LSB dynamic lib AMD64 Version 1,
dynamically linked, not stripped, no debugging information available

My Ruby installation is, indeed, a 32 bit install. That’s how the
package I installed compiled it. I tried changing that by recompiling
in 64 bit mode early in this whole saga, but it was an absolute
nightmare. I don’t think the make files of most of the Ruby libraries
play nicely with 64 bit compile options.

I suppose I could install the libraries from a 32bit MySQL installation
and rebuild the gem based on those…

Any other ideas?

7

Thomas H. wrote:

Solaris 10 x86 on a 64-bit Xenon server… Can anyone guess where this
is going?

It’s Xeon. Every time you say Xenon an Intel marketing team member
kills himself. Hm… carry on.

Oops, I mean I meant to do that, I mean oops… }:0

This looks like a Solaris bug:

http://bugs.opensolaris.org/view_bug.do?bug_id=6531439

If the workaround described there doesn’t work you might try getting the
mysql extension tarball and messing about with extconf (maybe
–with-mysql-lib=/usr/lib/amd64? ugh) and/or the Makefile.

You might also try strace/dtrace to see where the linker’s looking for
the library first, in case that workaround is incomplete.

Yuck.

This is a nudge in the right direction. I was monkeying around with the
libraries mentioned in the bug report, (originally all of them existed
in some form, dunno if links or files) and ln’ed when I meant to ls and
lost track of what I was doing. Strangely enough, it compiled without a
hitch immediately thereafter.

Sadly, it still doesn’t work…

andrewo@host:~/test# script/console
Loading development environment.

require ‘mysql’
LoadError: ld.so.1: ruby: fatal:
/usr/local/lib/ruby/gems/1.8/gems/mysql-2.7/lib/mysql.so: wrong ELF
class: ELFCLASS64 -
/usr/local/lib/ruby/gems/1.8/gems/mysql-2.7/lib/mysql.so
from /usr/local/lib/ruby/gems/1.8/gems/mysql-2.7/lib/mysql.so

I’ll keep messing with it.

Thanks for the help.

8

Andrew O. wrote:

Gerardo S. Gómez Garrido wrote:

You’re mixing 32-bit and 64-bit libraries.
My MySQL installation is 64 bit, and so as a result so are its
libraries.

My Ruby installation is, indeed, a 32 bit install. That’s how the
package I installed compiled it. I tried changing that by recompiling
in 64 bit mode early in this whole saga, but it was an absolute
nightmare. I don’t think the make files of most of the Ruby libraries
play nicely with 64 bit compile options.

I suppose I could install the libraries from a 32bit MySQL installation
and rebuild the gem based on those…

I tried this as well. I got the MySQL libraries off a Solaris x86 32
bit machine and copied over to my 64 bit machine. But after installing
the gem, the mysql.so is still 64 bit.

root@trinity:/opt/mysql/mysql/lib/32# file libmysqlclient.so
libmysqlclient.so: ELF 32-bit LSB dynamic lib 80386 Version 1,
dynamically linked, not stripped

root@trinity:/opt/mysql/mysql/lib/32# gem install mysql –
–with-mysql-config=/usr/local/mysql/bin/mysql_config
–with-mysql-lib=/usr/local/mysql/lib/32
Building native extensions. This could take a while…
Successfully installed mysql-2.7
1 gem installed

root@trinity:/opt/mysql/mysql/lib/32# file
/usr/local/lib/ruby/gems/1.8/gems/mysql-2.7/lib/mysql.so
/usr/local/lib/ruby/gems/1.8/gems/mysql-2.7/lib/mysql.so: ELF
64-bit LSB dynamic lib AMD64 Version 1, dynamically linked, not
stripped, no debugging information available
root@trinity:/opt/mysql/mysql/lib/32#

I’m about to give up and just reinstall mysql in 32 bit mode, but I
don’t want to give up whatever little speed edge I’m getting from the 64
bit version. I can’t be the first person to use sunfreeware ruby with
official mysql…

9

You have to tell Solaris where are the 32-bit libraries and the 64-bit
libraries. There are three environment variables for this purpose:

LD_LIBRARY_PATH
LD_LIBRARY_PATH_32
LD_LIBRARY_PATH_64

Since the 32-bit MySQL libraries are the exception, set
LD_LIBRARY_PATH_32 to /usr/local/mysql/lib/32 and leave your
LD_LIBRARY_PATH as it is, if you have one.