Bug #2891 make install-strip fails with syntax error
Submitted: 19 Feb 2004 6:05 Modified: 13 Dec 2004 21:00
Reporter: [ name withheld ] Email Updates:
Status: Closed Impact on me:
Category:MySQL Server: Installing Severity:S3 (Non-critical)
Version:MySQL 4.0.18 OS:MacOS (Mac OS X 10.3.x)
Assigned to: Lenz Grimmer CPU Architecture:Any

[19 Feb 2004 6:05] [ name withheld ]
The install-strip target fails with a syntax error. This target worked previously, and is needed by 
packagers to produce stripped binaries.

make install-strip
make[4]: Nothing to be done for `install-data-am'.
Making install in libmysql_r
/bin/sh ../mkinstalldirs /tmp/v/usr/lib/mysql
 /bin/sh ../libtool --mode=install /usr/bin/install -c -s libmysqlclient_r.la /tmp/v/usr/lib/mysql/
/usr/bin/install -c .libs/libmysqlclient_r.lai /tmp/v/usr/lib/mysql/libmysqlclient_r.la
/usr/bin/install -c .libs/libmysqlclient_r.a /tmp/v/usr/lib/mysql/libmysqlclient_r.a
/tmp/v/usr/lib/mysql/libmysqlclient_r.a: line 1: syntax error near unexpected token `newline'
/tmp/v/usr/lib/mysql/libmysqlclient_r.a: line 1: `!<arch>'
make[3]: *** [install-pkglibLTLIBRARIES] Error 2
make[2]: *** [install-am] Error 2
make[1]: *** [install-recursive] Error 1
make: *** [install-strip] Error 2

The libmysqlclient_r section is the first place where  /bin/sh ../libtool --mode=install occurs. I 
suspect there was a change to libtool that broke --mode=install for us on Panther Server (10.3.2). 

In the excerpt above, the line that reads "  /tmp/v/usr/lib/mysql/libmysqlclient_r.a" is supposed to 
be "ranlib   /tmp/v/usr/lib/mysql/libmysqlclient_r.a". Because the "ranlib" part is missing, it just 
tries to execute the ".a" file as a script, and gives a syntax error.

A work-around is to just use the install target, and strip the binaries manually.

How to repeat:
Download MySQL 4.0.18 source distribution and do the configure and make. Then instead of make 
install, do make install-strip.
[8 Jun 2004 18:39] Hartmut Holzgraefe
it doesn't work for linux, too, but with a different error message:

Making install in client
make[2]: Entering directory `/home/hartmut/projects/mysql/releases/mysql-4.0.18/client'
make[3]: Entering directory `/home/hartmut/projects/mysql/releases/mysql-4.0.18/client'
/bin/sh ../mkinstalldirs /usr/local/mysql/bin
 STRIPPROG='strip' /bin/sh ../libtool --mode=install /bin/sh /home/hartmut/projects/mysql/mysql-4.0.18/install-sh -c -s mysql /usr/local/mysql/bin/mysql
/bin/sh /home/hartmut/projects/mysql/mysql-4.0.18/install-sh -c -s .libs/mysql /usr/local/mysql/bin/mysql
/home/hartmut/projects/mysql/mysql-4.0.18/install-sh: /home/hartmut/projects/mysql/mysql-4.0.18/install-sh: No such file or directory
make[3]: *** [install-binPROGRAMS] Fehler 1
make[3]: Leaving directory `/home/hartmut/projects/mysql/releases/mysql-4.0.18/client'
make[2]: *** [install-am] Fehler 2
make[2]: Leaving directory `/home/hartmut/projects/mysql/releases/mysql-4.0.18/client'
make[1]: *** [install-recursive] Fehler 1
make[1]: Leaving directory `/home/hartmut/projects/mysql/releases/mysql-4.0.18'
make: *** [install-strip] Fehler 2
[11 Jun 2004 12:20] Hartmut Holzgraefe
I tested the install-strip target with 4.0.15 on both MacOS X 
and Linux without problems so this was introduced somewhere
between 4.0.15 and 4.0.18.

The actual bug (trying to execute a library after installation) 
on MacOS X happens within a call to libtool. 
libmysql/Makefile.am did not change at all between 4.0.15 and 
4.0.18, but the 4.0.18 release was created with libtool 1.5 
while libtool 1.4.2 was used for the 4.0.15 release.

So it looks like a libtool 1.5 bug to me ...
[13 Jun 2004 15:35] Hartmut Holzgraefe
I've verified that it is a bug in libtool 1.5,
when using the current libtool version 1.5.6 with
our sources the 'install-strip' target works fine
on both Linux and MacOS X.
[13 Dec 2004 21:00] Lenz Grimmer
Should now be resolved as we moved the building of the source distribution to a new build machine with more recent autotools/libtool installed. Sorry for the delay.