SUMMARY: mysql compile: "ld broken"

From: Ann Cantelow <cantelow_at_athena.csdco.com>
Date: Tue, 23 Nov 1999 17:22:14 -0700 (MST)

Hello. This was my question:
------------------------
> Hi. Has anyone been able to compile MySQL, the latest version, 2.23.27?
>
> I am on version 4.0D and I am stuck on this message:
>
> collect2: ld returned 1 exit status
> /usr/bin/ld:
> Unresolved:
> _exit

The documentation for Mysql says that ld is "broken" for this version of
DU (4.0D, no patches) and suggests using an *older* 4.0c version of ld.
--------------------------

Many, many thanks to Simon Greaves, who wrote:

> This is almost certainly a 'gcc -ism'. Try manually removing the '-lc'
> from the above line - sounds stupid I know, but it fixes similar problems
> when building packages like php3 (for me at least).
>

This proved to be the case. I used this command to run configure and
successfully compile the distribution:

env CC="cc -pthread" CFLAGS=-I./include CXX=gcc CXXFLAGS=-O3 ./configure \
   --with-low-memory --with-named-thread-libs="-lpthread -lmach -lexc"

I removed "-lc" from the with-named-thread-libs variable list recommended
in the docs, thanks to Simon's suggestion. If -lc is included in that
list, I get the above unresolved _exit symbol. _exit is in the libc
library, so removing it from the list must have left it free to get the
default libc from the system. I plan to write the MySQL developers to
tell them how this helped. The default for named-thread-libs does include
the -lc, so leaving out the named-thread-libs variable altogether didn't
help.

This was built with CC=cc and CXX=gcc per another suggestion in the
documents. I am hoping this doesn't cause a problem down the line.

Here's more detail:

If I use gcc for both CC and CXX, I run into a complaint about the format
of a c_asm.h file. The docs say to just put a blank c_asm.h file in
(dist)/include for that problem, but then there's an unresolved symbol for
asm. I could see that it was indeed being used in (dist)/strings/bfill.c.

I have plenty of memory, but a compile without --with-low-memory ran out
of memory on a yacc routine, if I recall correctly. I guess it hit a
loop somehow. The docs suggested the --with-low-memory workaround.

In the distribution INSTALL-SOURCE file, and identically in the included
mysql manual, there are some osf tips that deal with these issues, in two
sections, one for Alpha-DEC-Unix and one for Alpha-DEC-OSF1. Also the
general comments a the top of the "Problems Compiling?" section were
helpful.

There were a few compile warnings about char type conflicts, similar to
warnings I have seen on other compiled packages. I am hoping this will
not cause a problem with running the package.

Here is the statement where things were blowing up, when I had -lc
included in the configure named-thread-libs variable:

-----------------------------
gcc -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -O3
-DDBUG_OFF -O3 -fno-implicit-templates -o mysqld item.o item_sum.o
item_buff.o item_func.o item_cmpfunc.o item_strfunc.o item_timefunc.o
thr_malloc.o field.o key.o sql_class.o sql_list.o net_serv.o net_pkg.o
lock.o my_lock.o sql_string.o sql_map.o mysqld.o password.o hash_filo.o
hostname.o sql_lex.o convert.o sql_parse.o sql_yacc.o sql_base.o dfunc.o
sql_select.o sql_insert.o sql_update.o sql_delete.o procedure.o
item_uniq.o sql_test.o log.o init.o derror.o sql_acl.o unireg.o time.o
opt_range.o opt_sum.o records.o filesort.o handler.o sql_db .o crebas.o
sql_table.o sql_crypt.o sql_load.o mf_iocache.o field_conv.o sql_show.o
sql_udf.o ../isam/libnisam.a ../merge/libmerge.a ../heap/libheap.a
../mysys/libmysys.a ../dbug/libdbug.a ../regex/libregex.a
../strings/libmystrings.a -lm -lpthread -lmach -lexc -lc
collect2: ld returned 1 exit status
/usr/bin/ld:
Unresolved:
_exit
*** Exit 1
Stop.
*** Exit 1
Stop.


Best wishes to anyone in the future compiling this program. The previous
version 3.21.33 that I installed some time ago from binary runs great and
is very fast, except that it very occasionally loses a thread when under
moderate load. That binary no longer seems to be available on the MySQL
site, however, so I wonder if under heavy loads there might be more
problems with it. Our load is usually quite light. This 3.22.27 version
just compiled has some nice features added, and I hope it will be even
more stable than the 3.21 version has been for us.

Ann Cantelow
cantelow_at_athena.csdco.com
Received on Wed Nov 24 1999 - 00:24:00 NZDT

This archive was generated by hypermail 2.4.0 : Wed Nov 08 2023 - 11:53:40 NZDT