| Bug #4921 | Can't link application with libmysqld.a | ||
|---|---|---|---|
| Submitted: | 6 Aug 2004 10:42 | Modified: | 26 Sep 2006 22:23 |
| Reporter: | Jorge del Conde | ||
| Status: | Can't repeat | ||
| Category: | Server: Packaging | Severity: | S3 (Non-critical) |
| Version: | 4.0.20 - 4.1.3 | OS: | Linux (Linux) |
| Assigned to: | Target Version: | ||
[7 Aug 2004 16:33]
Alexey Stroganov
Working on compiling of DBD::mysqlEmb I found out several different issues concering embedded library. As they are similar to bug reported above I put my findings here. 1. Original problem could be easily fixed by adding of libmygcc library to LIBS variable. LIB= ... -lmygcc Good background for such type of linking problems one can find here: http://groups.google.com/groups?q=TCL+shared+C%2B%2B+__builtin_new&hl=en&lr=lang_en&selm=E... 2. We included libmygcc.a library only in binary distribution. I think we should also put this library in mysql-devel package too. 3. Linking of application with embedded server library from RPM package 'Embedded server' for 4.1.3 requires several additional libraries (libssl, libcrypto, libdb) that are not mentioned in embedded section of mysql_config from 4.1.3 server RPM. 4. BUG#959 (http://bugs.mysql.com/bug.php?id=959) was fixed in 4.1 but not in 4.0 as reported, so maybe it has sense to backport it to 4.0.
[11 Aug 2004 14:46]
Lenz Grimmer
I have now pushed a fix to add libmygcc.a to the RPM packages as well:
ChangeSet@1.1949, 2004-08-10 16:50:29+02:00, lenz@mysql.com
- Added libmygcc.a to the "devel" RPM subpackage (required to link
applications against the the embedded server libmysqld.a)
(BUG#4921)
Jorge, can you please verify that using -lmygcc resolves this issue for you when using
the binary
tarball?
Ranger, BUG#959 was actually fixed in 4.0 as well. I am keeping this bug open as "Need
Feedback",
but it's not a Showstopper bug anymore.
[13 Aug 2004 14:59]
Lenz Grimmer
Even adding libmygcc.a does not resolve all problems - the linking still fails with an unresolved symbol "__ctype_b" (which is only defined in glibc-2.2.5)
[4 May 2005 16:37]
Lenz Grimmer
Putting this bug into "Won't fix", as there is no way to resolve it for the statically linked binary. It's not an issue for the dynamically linked binaries.
[23 Jul 2006 12:06]
Hartmut Holzgraefe
Sorry for re-opening this one, but i ran into the same issues when using mysql-max-4.1.20-pc-linux-gnu-i686.tar.gz so this is not limited to static binary packages. First of all -lmygcc should be added to the "mysql_config --libmysqld-libs" output where needed (see also bug #19561). Then if we know that it's not possible to link against libmysqld.a on non-glibc2.2 systems (with 2.3 being the standard all over the place these days), why do we include the library in such distribution packages at all? And last not least: i'm getting the same "undefined reference to `__ctype_b'" errors when trying to compile against mysql-max-4.1.20-pc-linux-gnu-i686 which isn't supposed to be static, is it? As the 5.0 and 5.1 binary tarballs don't include the embedded library i don't know whether the same problems would apply to these. Note that this is a problem specific to the distributed binaries, when compiling stuff myself with BUILD/compile-pentium-max or BUILD/compile-pentium-debug max this is not an issue (on SuSE 10.0, so using gcc 4.0.2 and glibc 2.3.5) The attached bug4921.tar.gz is a very basic test project that can be used to reproduce these problem, just do a "configure --with-mysql=...; make" (note: i had to add -lssl to the mysqld linker flags, too, to prevent linker errors, i'll create a seperate bug report for that).
[23 Jul 2006 12:51]
Hartmut Holzgraefe
test project
Attachment: bug4921.tar.bz2 (application/x-tar, text), 187.69 KiB.
[24 Jul 2006 11:53]
Lenz Grimmer
Assigning to Kent, as I don't work on build issues anymore...
[13 Sep 2006 16:07]
Carlos Javier Alcala Helguero
Hi, I am trying to configure (from source) the last PHP 5.1.6 with the last MYSQL 5.0.24a on INTEL DUAL CORE x_86_64 server. When you try to configure php with links to /usr/lib64 is still looks in /usr/lib for the .so files. So... or is a BUG from PHP or a bug grom MYSQL? or is there special instruction to configure PHP on 64bit. I did get PHP to (only) configure by using the --with-libdir=lib64 ./configure \ --with-libdir=lib64 \ --with-mysql=/usr/local/mysql \ --with-mysqli=/usr/local/mysql/bin/mysql_config \ --enable-soap \ --enable-calendar \ --enable-ftp \ --with-zlib-dir=/usr \ --with-gd \ --with-jpeg-dir=/usr \ --with-png-dir=/usr \ --with-tiff-dir=/usr \ --with-freetype-dir=/usr \ --enable-exif I solve the problem can't locate libmysqlclient in /usr/local/mysql But I have to create a sys link for the mysql lib for the configure will find the lib files. ln -s /usr/local/mysql/lib /usr/local/mysql/lib64 Does anyone know that the right way to configure php with mysql support on 64bit system is???? My method worked but I don't think it is the right way. Or maybe is there a bug(PHP or MYSQL) on 64BITS systems to find the shared libs.
Description: Linking with the embedded server library (libmysqld.a) from our Linux binary & rpm distributions, produces a bunch of errors. This problem doesn't happen if one compiles mysql from source and then links to the custom compiled libraries. How to repeat: Try to compile the following code: Makefile -------- SHELL=/bin/sh INSTALL= mv CC=gcc CFLAGS= -I/usr/local/mysql/include OBS= main.o SRC= main.c LIBS= -L/usr/local/mysql/lib -lmysqld -lpthread -lz -lcrypt -lnsl -lm -lpthread -lc -lnss_files -lnss_dns -lresolv -lc -lnss_files -lnss_dns -lresolv -lrt NEW= main MAKES= Makefile $(NEW): $(OBS) $(CC) $(CFLAGS) -o $(NEW) $(OBS) $(LIBS) clean: rm -f *.o $(NEW) core main.c ------- #include <mysql.h> #include <stdlib.h> static char *server_args[] = { "this_program", "--datadir=.", "--key_buffer_size=32M" }; static char *server_groups[] = { "embedded", "server", "this_program_SERVER", (char *)NULL }; int main(void) { if (mysql_server_init(sizeof(server_args) / sizeof(char *), server_args, server_groups)) exit(1); mysql_server_end(); return 0 } jorge-mysql_code/embedded> make gcc -I/usr/local/mysql/include -c -o main.o main.c In file included from /usr/local/mysql/include/my_global.h:307, from main.c:2: /usr/include/asm/atomic.h:40:2: warning: #warning Using kernel header in userland program. BAD! gcc -I/usr/local/mysql/include -o main main.o -L/usr/local/mysql/lib -lmysqld -lpthread -lz -lcrypt -lnsl -lm -lpthread -lc -lnss_files -lnss_dns -lresolv -lc -lnss_files -lnss_dns -lresolv -lrt /usr/local/mysql/lib/libmysqld.a(handler.o)(.gnu.linkonce.d.__vt_7handler+0x38): undefined reference to `__pure_virtual' /usr/local/mysql/lib/libmysqld.a(handler.o)(.gnu.linkonce.d.__vt_7handler+0x40): undefined reference to `__pure_virtual' /usr/local/mysql/lib/libmysqld.a(handler.o)(.gnu.linkonce.d.__vt_7handler+0x44): undefined reference to `__pure_virtual' /usr/local/mysql/lib/libmysqld.a(handler.o)(.gnu.linkonce.d.__vt_7handler+0x48): undefined reference to `__pure_virtual' /usr/local/mysql/lib/libmysqld.a(handler.o)(.gnu.linkonce.d.__vt_7handler+0x4c): undefined reference to `__pure_virtual' ... etc