Outstanding! That means you are getting somewhere, and eliminates a lot of potential issues from consideration when you are trying to identify the source of the problem. Hopefully, you “info.php” was a “phpinfo()” run, so that you could inspect your PHP copnfiguration and confirm that everything your thought was installed actually was installed and is working correctly.
I’m assuming that you meant to say you can’t “access info.php, can’t see my index.php page, or anything else.”
Once you “setup” your website, you introduce a whole set of potential problems, and it could any one thing, more than one thing, or any combination of things involving that “website setup”. From the error messages you report, some of the potential issues could include:
Permissions issues with the files or directories that comprise the “self-extracting web application” you are trying to install. This is especially likely if you prepared the “self-extracting” archive of the application as it was set-up/running on another server (with different settings for PHP? Not running PHP-CGI under suEXEC?, etc). Generally, running PHP-CGI on DreamHost shared server you should set all directories to 755 (not just the cgi-bin) and all files to 644. If everything is working you can experiment with other permissions, but start with this setup, even if the documentation from the script tells you otherwise.
Extraneous characters before the opening PHP tags and/or after the ending PHP tag in one or more of the file in that application; this is often the cause of “premature end of script headers” when running PH-CGI. This information might be helpful to you in investigating the “premature end of script headers” error(s).
The structure of the application’s file layout and program flow could be different then how you are set-up on DreamHost (.htaccess files with directives in various directories, different “base” directory/file system structure for the application’s files, etc., is the application even compatible with running PHP-CGI and opposed to mod_php?)
At this point, considering what you have running, I feel it is more likely to be (at least initially) “something to do with your self-extract web application”.
The first thing I would do to try to resolve this is get back to where you had a functioning domain with a working custom PHP.4.4.7; at that point, nothing is broken.
At this point, you have an environment that should work, you just need to make sure any necessary changes (correction of “bad” line endings in files, assorted file and directory permissions, etc) are in place in that “application”.
This might take some doing - I can’t tell because I have not seem the application. First, what is the web application you are trying to install?
Is this an Open Source application you are using, or is is proprietary code? It’s pretty easy to find help with an Open Source application that many use, while it can be a lot harder with proprietary, commercial, or custom software.
Is any of the code encrypted or “protected” with zend, ioncube or some other “crippling” function?
If the application is one that you purchased, once you have a working domain with the proper PHP-CGI installed per the programs requirements, you should contact the author for help in installing it on DreamHost. DreamHost is now a large enough and popular enough webhost that most authors are willing to help you get it installed on DreamHost (and all should help you, if you paid for it).
If it is Open Source, make sure you are trying to install from the *original installation archive/tarballk, etc, using the most current revision of the software that is compatible with your data, and not just moving your code from another host.
The differences between host set-ups are very likely to be different, and if the install process for the application read environment variables from the other host, those “config” values are not likely to work on DH.
Though there is no indication in the error messages you have shared that indicates MySQL is involved at this point, since you mentioned MySQL is used in your application make sure your db is backed up from it’s prior home. That way, worst case, if you can succeed in installing the application on DreamHost, you should be able to import your data from the old host into your new DreamHost db (which you will have to create, in the CP, before installing the application).
First things first: Get your domain back in a usable condition with a working PHP, and work forward from that point to determine what/where you application breaks.