ld: fatal: relocations remain against allocatable but non-writable sections collect2: ld returned 1 exit status
Google search says to use GNU ld, but that didn't help matters any.
Right now, it's either (1) --disable-shared set, MySQL 4.1.7 completes the 'make' successfully but there are unresolved libmysqlclient.a symbols, or (2) --disable-shared NOT set and MySQL 4.1.7 fails during the make at the point where libtool is handling libmysqlclient.la
Neither seems like fun to me. Anyone have any other ideas/pointers?
--V
V. M. Brasseur wrote:
Unfortunately, the --disable-shared is intentional. For various reasons, our programs use static libraries whenever possible rather than dynamically linking.
Do you think the LDFLAGS and/or --enable-libgcc still help for static libraries?
Many thanks for your help so far,
--V
Ken Menzel wrote:
I ran into problems trying to use static libraries on Solaris 9.
I think you may not really want --disable-shared, the shared libs do make life a bit easier.
But try these solutions: LDFLAGS="$LDFLAGS -L/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/3.0/ -lgcc" or --enable-libgcc if you are using a recent gnu configure.
This link the gcc lib with your program.
I don't know what you are trying to link but here is a php reference. http://bugs.php.net/bug.php?id=16826&edit=1
----- Original Message ----- From: "V. M. Brasseur" <[EMAIL PROTECTED]> To: "MySQL Listserv" <[EMAIL PROTECTED]> Sent: Wednesday, November 03, 2004 1:18 PM Subject: Undefined symbols compiling against 4.1.7 on Solaris 2.8
We're trying to get 4.1.7 to play nicely with our code, but something isn't cooperating.
First of all, the MySQL installation: Version 4.1.7, compiled from source using GCC 3.3. The source compile is required because we need a lot of default settings to use our own paths. This is the configure used for the compile (some values altered here to protect the innocent):
CC=gcc CFLAGS="-O3" \
CXX=gcc CXXFLAGS="-O3 -felide-constructors -fno-exceptions -fno-rtti" \
./configure --prefix=/path/to/mysql \
--libexecdir=/path/to/mysql/bin \
--with-mysqld-user=ouruser \
--with-unix-socket-path=/path/to/mysql.sock --with-tcp-port=ourport \
--without-docs --without-bench --with-extra-charsets=complex \
--enable-thread-safe-client --enable-local-infile \
--localstatedir=/path/to/mysql/data \
--with-prefix=/path/to/mysql \
--with-low-memory --enable-assembler --disable-shared
It appears to function well on its own. However, when attempting to compile a program which requires libmysqlclient.a...
compiling -o progname /path/to/progname.c Undefined first referenced symbol in file __floatdisf /path/to/mysql/lib/libmysqlclient.a(libmysql.o) __floatdidf /path/to/mysql/lib/libmysqlclient.a(libmysql.o) __cmpdi2 /path/to/mysql/lib/libmysqlclient.a(libmysql.o) ld: fatal: Symbol referencing errors. No output written to progname compile:error=256,command=compiling -o progname /path/to/progname.c
It's worth noting that we are only experiencing this problem on Solaris 2.8. Another 4.1.7 installation on OSF1 5.1 is chugging along nicely with no complaints.
Google contains many references to these undefined symbols, encountered mostly when compiling other products. Yet none of those references contain an actual SOLUTION to the problem.
Could someone out there with a bit more ld/gcc/C API experience than I have (which is not setting the bar high, I assure you) lend a hand dispersing these clouds?
Many thanks,
--V
-- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
-- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
