MySQL Bugs: #18154: Compile problem on FreeBSD

Bug #18154	Compile problem on FreeBSD
Submitted:	11 Mar 2006 14:23	Modified:	15 Jul 2006 15:04
Reporter:	Tim Bishop	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server	Severity:	S3 (Non-critical)
Version:	5.0.22, 5.0.18	OS:	FreeBSD (FreeBSD 5.2.1)
Assigned to:		CPU Architecture:	Any

Description:
First off, I only get this problem on one machine, but I think it's actually uncovered a separate issue. Please bear with me.

I'm compiling mysql-5.0.18 using the FreeBSD database/mysql50-client port. I get the following seg fault during the build:

Making all in extra
if cc -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I../include  -I../sql     -DDBUG_OFF -O -pipe -mcpu=pentiumpro -D_THREAD_SAFE -MT comp_err.o -MD -MP -MF ".deps/comp_err.Tpo" -c -o comp_err.o comp_err.c;  then mv -f ".deps/comp_err.Tpo" ".deps/comp_err.Po"; else rm -f ".deps/comp_err.Tpo"; exit 1; fi
/usr/local/bin/libtool --preserve-dup-deps --mode=link cc  -DDBUG_OFF -O -pipe -mcpu=pentiumpro -D_THREAD_SAFE    -o comp_err  comp_err.o ../mysys/libmysys.a  ../dbug/libdbug.a ../strings/libmystrings.a -lc_r -lcrypt -lm  -lc_r
mkdir .libs
cc -DDBUG_OFF -O -pipe -mcpu=pentiumpro -D_THREAD_SAFE -o comp_err comp_err.o  ../mysys/libmysys.a ../dbug/libdbug.a ../strings/libmystrings.a -lcrypt -lm
../extra/comp_err  --charset=../sql/share/charsets  --out-dir=../sql/share/  --header_file=../include/mysqld_error.h  --name_file=../include/mysqld_ername.h  --state_file=../include/sql_state.h  --in_file=../sql/share/errmsg.txt
Segmentation fault (core dumped)
*** Error code 139

Stop in /usr/ports/databases/mysql50-client/work/mysql-5.0.18/extra.

It's comp_err that's sefaulted in the my_stat call. A bit of poking lead me to this line of code:

if (!my_stat(outfile, &stat_info,MYF(0)))

And I deduced that it segfaults when outfile is ../sql/share/japanese-sjis. That directory doesn't exist, so first up maybe there's a problem with my_stat?

Anyway, this led me to question why it was looking for a directory that doesn't exist. Where does it get the list? Looking at ../sql/share/errmsg.txt it has at the top:

languages czech=cze latin2, danish=dan latin1, dutch=nla latin1, english=eng latin1, estonian=est latin7, french=fre latin1, german=ger latin1, greek=greek greek, hungarian=hun latin2, italian=ita latin1, japanese=jpn ujis, japanese-sjis=jps sjis, korean=kor euckr, norwegian-ny=norwegian-ny latin1, norwegian=nor latin1, polish=pol latin2, portuguese=por latin1, romanian=rum latin2, russian=rus koi8r, serbian=serbian cp1250, slovak=slo latin2, spanish=spa latin1, swedish=swe latin1, ukrainian=ukr koi8u;

Removing the japanese-sjis entry from this line fixes my compile problem. Maybe that line shouldn't be there for a missing language?

Obviously since it's only segfaulting on this one machine there's probably another issue somewhere (it does it on 5.1.x too, btw), but hopefully I've uncovered another problem or two.

How to repeat:
See above.

Suggested fix:
Remove japanese-sjis entry from sql/share/errmsg.txt?

Thank you for a problem report. Can you, please, try to find out the real configure command line used by that FreeBSD port?

The configure command (taken from the top of config.log) is:

./configure --localstatedir=/var/db/mysql --without-debug --without-readline --without-libedit --without-bench --without-extra-tools --with-libwrap --with-mysqlfs --with-low-memory --with-comment=FreeBSD port: mysql-client-5.0.18_1 --enable-thread-safe-client --enable-assembler --with-berkeley-db --with-named-thread-libs=-lc_r --without-server --prefix=/usr/local --build=i386-portbld-freebsd5.2.1

Sorry for a long delay with this report. Please, try to repeat with a newer version, 5.0.20a and, if possible, on FreeBSD 5.3 or 5.4. We have no 5.2.1 available for testing.

I can confirm the problem still happens with 5.0.21. And I can also confirm the fix/workaround I suggested still works.

Sorry for a long delay with this bug. I had spent some time trying to repeat on FreeBSD 5.4 (but that machine is not working properly anyway). Then I moved to FreeBSD 6.0. I was able to build 5.0.22 without any error messages (and your workaround applied) using:

./configure --prefix=/home/mysqldev/valeriy/dbs/5.0 --without-debug --without-readline --without-libedit --without-bench --without-extra-tool --enable-thread-safe-client --enable-assembler --with-pic --disable-shared --without-server
make clean; make

(the difference is --with-pic --disable-shared added and --with-named-thread-libs=-lc_r removed).

mysqldev@bsd60$ uname -a
FreeBSD bsd60.mysql.com 6.0-RELEASE FreeBSD 6.0-RELEASE #0: Thu Nov  3 09:36:13
UTC 2005     root@x64.samsco.home:/usr/obj/usr/src/sys/GENERIC  i386
mysqldev@bsd60$ gcc --version
gcc (GCC) 3.4.4 [FreeBSD] 20050518
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Please, check, is this configure command line works for you.

Sorry for the delayed reponse. I'm not sure what you're asking me to do. What do you want me to test those configure flags with? 5.0.22 with my change? or just vanilla 5.0.22?

Please, test with vanilla 5.0.22 on your FreeBSD 5.2.1, without your change. Inform about the results.

5.0.22 compiles fine with those compile options.

So, last version, 5.0.22, does not have this problem.

5.0.22 has exactly the same problem, and still requires the fix. However, you suggested different configure flags which worked around the problem.

This looks like a problem with libtool and FreeBSD.
The "-lc_r" passed by the port system in PTHREAD_LIBS
is removed by libtool. But as configure did detect
thread support, this means that the source is compiled
to use threads, but linked with a non thread safe libc.

The reason you can see this for one of several compiles
only, is likely because of slightly different FreeBSD 5.0
version. Looking in "/usr/ports/Mk/bsd.port.mk" there
seems to be some back and forth about using the newer
kernel thread support or not

 .if ${OSVERSION} < 500016
 PTHREAD_CFLAGS?=    -D_THREAD_SAFE
 PTHREAD_LIBS?=      -pthread
 .elif ${OSVERSION} < 502102
 PTHREAD_CFLAGS?=    -D_THREAD_SAFE
 PTHREAD_LIBS?=      -lc_r
 .else
 PTHREAD_CFLAGS?=
 PTHREAD_LIBS?=      -pthread
 .endif

I can reproduce the problem on FreeBSD 6.0 if
forcing PTHREAD_LIBS to "-lc_r"

 % cd /usr/ports/databases/mysql50-server
 % make PTHREAD_LIBS=-lc_r

Both these lines to build passes the failing point

 % make PTHREAD_LIBS=-lpthread
 % make LDFLAGS=-pthread PTHREAD_LIBS=no

The second one is likely the "safest" for the
FreeBSD version you see the problem (but if the
port triggers other port builds and PTHREAD_LIBS
is passed down to these builds, it will likely
break).

Could not 100% verify the solutions as I don't
have access to the exact version of FreeBSD
that shows this problem.

Ok, I'm happy about the issues with threading libraries and FreeBSD. I don't think we need to worry too much about whether MySQL builds on the now obselete FreeBSD 5.2.1.

But, I'd like to know if that additional entry in sql/share/errmsg.txt for japanese-sjis is a mistake or not? My gut feeling at the beginning was that it shouldn't have been there.

Either way, after that's been looked at, feel free to close this bug.

japanese-sjis is a valid separate locale supported on all platforms. So, it should be in that errmsg.txt file.