Segmentation fault (core dumped) with self-complied mysql-5.1.9-beta.tar.gz
There are issues with this question that suggest a fundamental lack of familiarity with MySQL.


  After I input sudo bin/mysqld_safe --user=mysql &amp;, I must wait for a very long time. Why is that? 


What did you expect to happen?  Here are a couple of examples of startup behavior from other versions:

MySQL 5.0.45

$ sudo bin/mysqld_safe
Starting mysqld daemon with databases from /var/lib/mysql


MySQL 5.5.17

$ sudo bin/mysqld_safe
130320 20:04:20 mysqld_safe Logging to '/var/log/mysql/error.log'.
130320 20:04:20 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql


Nothing else is supposed to happen.  So... what you're seeing is normal, so far.  You can wait an infinite amount of time, and MySQL isn't normally going to say anything else on the console.  It's a server daemon, not an interactive program.

What does the MySQL error log say?  There's nothing here, yet, to tell us that your server isn't actually running just fine.

gaoyu@FlashGroup:~/mysql-5.1.9$ bin/mysql
Segmentation fault (core dumped)


Interesting, but unrelated to the other issue... bin/mysql is not MySQL Server, it's the MySQL command line client.  This could be a defect in the bundled or your local libedit, or curses, or SSL, or any other library that's involved... but if you can get the server working, you can connect to it with any newer version client, so the inability to compile a working client might not be particularly relevant, depending on the nature of what's happening here.

You also appear to be trying to start with a debug build, which seems like a backwards approach, since the debug instrumentation can change the behavior of the server.  

But this discussion all seems academic, since, as has already been aptly stated, MySQL 5.1.9 is a fundamentally flawed codebase to try working from.  Your code might be great, but you're working against a base that was not production quality.

In fact, it's a beta version that came out almost 7 years ago, and it took two and a half years' worth of releases after that one before the MySQL 5.1 release series achieved General Availability status.  

It seems inconceivable that 5.1.9 could be relevant to anyone, anywhere, when there were still major, major defects in that code... but granting, for a moment, the assumption that it is... then it seems like the bottom line is that if you have some 5.1.x-related add-on source code you're working with, there is not any intrinsic reason why it would not be equally usable with newer 5.1.x releases... 5.1.68 was released in 2013.  

Accomplish what you want to accomplish with 5.1.67 (my current production choice for 5.1 constrained environments) or 5.1.68 and there should be very few incompatibilities when you back-port to prior releases as long as you stay within 5.1.x.

Testing whether you can actually compile the newer versions of 5.1 successfully might tell you something about your build environment, too.