MySQL Bugs: #11913: mysql_install_db is not aware of --program-suffix configure option

Bug #11913	mysql_install_db is not aware of --program-suffix configure option
Submitted:	13 Jul 2005 13:15	Modified:	8 Dec 2016 9:04
Reporter:	[ name withheld ]	Email Updates:
Status:	Won't fix	Impact on me:	None
Category:	MySQL Server: Installing	Severity:	S3 (Non-critical)
Version:	4.1.12 (source), 5.1-bzr, all	OS:	Any
Assigned to:		CPU Architecture:	Any

Description:
If you use --program-suffix (I gues it is the same with --program-prefix) configuration option then all the executables have some suffix added. However the mysql_install_db script is built with references to non-suffixed (prefixed) executables and thus failes.

How to repeat:
install from source:
> ./configure --program-suffix=xxx
> make
> make install
> $bindir/mysql_install_db

Didn't find $libexec/mysqld
You should do a 'make install' before executing this script

Suggested fix:
The script mysql_install_db shoulbe be made aware of --program-preffix option in order to try to run $libexec/mysqldxxx instead of $libexec/mysqld.

The affected executables called from the script are my_print_defaults, mysqld, resolveip and mysql_create_system_tables. 

When I changed them to versions with apropriate suffix the script worked.

I'm looking at this script and it assumes 'mysqld' for the binary name. There's nothing that I know of in a distribution that makes it possible to know what the binary for a given program should be named or suffixed as. I would suggest that I add a --suffix option to the mysql_install_db script, which the user would supply whatever needs to be the program's suffix should it be anything other than 'mysqld'.

It is my impression that mysql_install_db script is built during the compilation (installation?) and can access the configuration options. How else could be variables like basedir set to correct values? Basedir has to be imported somehow from the configuration options (--prefix option). 

I would suggest the same method to import the --program-suffix (--program-prefix) configuration option to this script and use this variables to concatenate program names.

ready for review. I added @program_transform_name@ to Makefile.am and utilise that in mysql_install_db.sh to interpolate all binary names into variables that are regexed with sed to contain the proper program suffix supplied by --program-suffix

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/internals/27940

per Jim Winstead, I need to modify all the other scripts to be aware of --program-suffix

As this will require an extensive modification to multiple scripts, will fix later

I add the same problem with the version 5.1.7

Bug still exists in current version:

$./bin/mysql_install_dbbug11913 --basedir=. --datadir=./data

FATAL ERROR: Could not find my_print_defaults

The following directories were searched:

    ./bin
    ./extra

If you compiled from source, you need to run 'make install' to
copy the software into the correct location ready for operation.

If you are using a binary release, you must either be at the top
level of the extracted archive, or pass the --basedir option
pointing to that location.

Also it affects MySQL Test Suite:

$./mysql-test-run.plbug11913 alias
**** ERROR **** You must start mysql-test-run from the mysql-test/ directory

Same problem seems to exist when using CMAKE_EXECUTABLE_SUFFIX with newer CMake based builds.

Looking at 5.6.12 source both scripts/mysql_install_db.sh and scripts/mysql_install_db.pl.in refer to the mysqld binary as just "mysqld" or "mysqld.exe" without taking the possibility of CMAKE_EXECUTABLE_SUFFIX being set into account ...

Posted by developer:
 
This is indeed a real bug, but with the time that has passed, the impact is much diminished: MySQL 5.7 and newer do not use mysql_install_db and our Linux packages from 5.6 and upwards do not use it. Weighing that against the risk and considerable effort of fixing this properly, I am thus closing this as Not feasible to fix.