> On Fri, 2010-05-14 at 10:28 +0200, Joerg Bruehe wrote:
>>> The following error just won't go away:
>>> 100513 21:53:35 [ERROR] /tmp/msource/libexec/mysqld: unknown option
>>> ... even after I manually search for the location where this flag is
>>> passed, and manually edit that source to never issue it.
>> I am surprised to see that option still occurring in a file in 5.1, that
>> looks wrong. But I doubt this is really the problem, because in that
>> case many more users would suffer from it, internal tests included.
> I doubt many more users try to create a clean test installation of
> MySQL, in a specific directory, on a machine that already has MySQL
Correct - but if really the occurrence in "mysql_install_db" were the
issue, then it would also occur with a single install.
>> Are you really sure that this option does not show up in your "my.cnf",
>> or any other config file read by the server?
>> It was still used and supported in 5.0, so any remnant 5.0 config file
>> read by your 5.1 server might cause this problem.
> Well, that's precisely the problem: I am doing a clean ./configure;
> make; make install cycle, and I am producing a clean my.cnf, but
> "somehow" the mysql tools are trying to execute something else (which
> must pick up my existing 5.0 installation. They must be picking up
> something from the path.
I fear so, too.
You didn't exactly specify your platform, I can just tell it is some
Unix. I propose you check for all existing "my.cnf" and do a "ls -lu" on
them, then start your new server, then do that "ls -lu" again. I suspect
one (or more) of them will be read by the new server upon startup.
> This is just wrong. I should be able to build a clean MySQL and start it
> independently, even if I already have a previous, pre-packaged MySQL
> instance on the test machine.
> I believe the problem is in the MySQL tools. I shouldn't have to remove
> my existing MySQL installation just to build and test some other MySQL
> installation. That's exactly the whole rationale behind having a
> --prefix in ./configure, a --basedir, and so forth.
It is a question of policies and preferences.
MySQL traditionally supports both global, system-wide configuration
files and local ones, by instance.
Changing that might affect existing installations, so it can't be done
lightly and needs decent design and announcement.
Joerg Bruehe, MySQL Build Team, Joerg.Bruehe@stripped
Sun Microsystems GmbH, Komturstrasse 18a, D-12099 Berlin
Geschaeftsfuehrer: Juergen Kunz
Amtsgericht Muenchen: HRB161028