Has anyone tried this yet, besides me?

Co-compiling Apache 2.0.52, PHP 5.0.2, MySQL 5.0.2

Miserable failures for Slackware, can't find sources, bad --prefix problems, fail to set permissions and put executables in proper directory, and so on.

Example, using --prefix=/Apache everything got put in that directory, so, no executables in /bin which is where they belong for Slackware. Commands were also not executable, and no symlinks were installed.

A week of reading all the documents didn't much help either.

There are more than ten directory options in these programs, with no explanation of which affects which files.

Does anyone have the list of default directories for Slackware 10?

From Apache Layout:

<Layout Slackware10>
prefix: /usr /* This looks like correct prefix fixes next line */
exec_prefix: ${prefix} /* checkgid was /usr/bin is /Apache/bin Fix This! */
bindir: ${prefix}/bin /* httpd here by mistake, prefix must have been /usr */
sbindir: ${prefix}/sbin /* Apach2 no /sbin went to /Apache/bin Needs Fix! */
libdir: ${prefix}/lib /* .so files in /Apache/lib not /usr/lib :is prefix */
libexecdir: ${prefix}/lib/apache /* httpd.exp in /usr/libexec/apache in /Apache/modules */
mandir: ${prefix}/man /* man pages in old/man and /Apache/man
sysconfdir: /etc/httpd/conf /* Slackware is /etc */
datadir: /var/www /* old/var/www/htdocs/ vs /Apache/htdocs/ */
installbuilddir: ${datadir}/build /* no Build for old binary. */
errordir: ${datadir}/error /* none in old binary for custom error pages */
iconsdir: ${datadir}/icons /* /var/www/icons/ vs /Apache/icons/ */
htdocsdir: ${datadir}/html /* /var/www/htdocs vs /Apache/htdocs old Redhat */
manualdir: ${datadir}/manual /* /var/www/manual/ vs /Apache/manual/ */
cgidir: ${datadir}/cgi-bin /* /var/www/cgi-bin vs /Apache/cgi-bin */
includedir: ${prefix}/include/apache /* old/usr/include/apache/ vs /Apache/include/ */
localstatedir: /var /* /var/httpd.pid vs /Apache/logs/httpd.pid ??? */
runtimedir: ${localstatedir}/run /* same as above line ??? */
logfiledir: ${localstatedir}/log/httpd /* /var/log/apache vs /Apache/logs/ */
proxycachedir: ${localstatedir}/cache/httpd /* /var/cache vs maybe tmp file ??? */
</Layout>

Another question is: do you have to have the binary version installed for these programs to find the .so files? That seems really stupid, Apache2 did compile and run, however, when I removed the old Apache, PHP, and MySQL. PHP couldn't find the .so files for mysql. And, although PHP said it compiled okay and gave lots of good output, there was no trace of PHP on the Slackware system! I mean, it was gone with the exception of the source directory. Does this mean that co-compiles are dependant on existing binary installs!!! Gee, bummer.

Correct this list if you know how.

Example: /var/named/run/host.pid went to /Apache/val/logs/host.pid
Don't even know how the original layout accomplished that!

Similarly, layouts for PHP and MySQL if anyone has them for Slackware.

Lastly, for all developers and gcc gurus: every compile should generate a "packing list," that is, exactly what files were installed, where, what files were removed, from where. That is Standard Operating Procedure!

No packing list with any of these compiles. Guess how many hours it takes to find out what the compile did?

Triple dog dare ya!

And that's my last post until I figure it out.

sorry for reply asking for a totally different thing but i was trying for 10 hours till now trying to get mysql 5.0.2 to work and i cant install it am using debian unstable so if u could help me i would really appreciate it so much
thanks

It's always in the layout, as in "prefix" and "execprefix" or whatever.

Sorry about the delay in reply. Been working on the very same problem. MySQL and PHP assume certain paths, which are different for every distribution. Go find the Apache2 sources and Apache1 sources, then find the LAYOUT file and the other .layout files and you'll find in one of them the correct paths for Debian.

From Apache2 config.layout:

# Debian layout
<Layout Debian>
prefix:
exec_prefix: ${prefix}/usr
bindir: ${exec_prefix}/bin
sbindir: ${exec_prefix}/sbin
libdir: ${exec_prefix}/lib
libexecdir: ${exec_prefix}/lib/apache2/modules
mandir: ${exec_prefix}/share/man
sysconfdir: ${prefix}/etc/apache2
datadir: ${exec_prefix}/share/apache2
iconsdir: ${datadir}/icons
htdocsdir: ${prefix}/usr/share/apache2/default-site/htdocs
manualdir: ${htdocsdir}/manual
cgidir: ${prefix}/usr/lib/cgi-bin
includedir: ${exec_prefix}/include/apache2
localstatedir: ${prefix}/var/run
runtimedir: ${prefix}/var/run
logfiledir: ${prefix}/var/log/apache2
proxycachedir: ${prefix}/var/cache/apache2/proxy
infodir: ${exec_prefix}/share/info
installbuilddir: ${prefix}/etc/apache2/build
errordir: ${datadir}/error
</Layout>
and the option is "--with-layout=debian" or something similar. You can also change the configure file, although they are massively huge files that take a while to load, and then find the 'prefix' and other defines. Usually, it looks like:

prefix="/usr"

or some such. MySQL, PHP, and most other compiles do not yet use the Apache approach of a config.layout file, but they should.

I am writing a specification to change compiles, using, among others, the file LAYOUT not as a README, but as the actual derived layout for all compiles on a given system.

I'm also working on getting rid of a lot of configure garbage script that can be replaced with one-liner files, like VERSION, ARCHITECTURE, DISTRIBUTION, OPTIONS, and so on. That way, configure, automake, and libtool can parse a file one time to arrive at the needed information. This should trim down that 3.3 meg PHP configure file!

You need to read the options section and configuration sections of Apache to figure out how to configure MySQL. It's much better than the MySQL documentation, and gets straight to the point.

But the "file" approach to setting the compile options is much simpler and saves a lot more time and eliminates a ton of unneeded Bash, Awk, Perl, Sed, and all the other scripts.

Debian's layout doesn't seem different from Slackware, at least not to me.

I'm also being quite crazy and suggesting moving everything to a place where it makes more sense:

source to SrcDir='/Source'
Binaries to BinDir='/Binaries'
DataDir='/Data/${programname}'

and defining the variable programname to build trees that can be more easily deleted, thus deleting the entire program by deleting that directory, like:

BinDir='/bin/${PROGRAMNAME}'
LibDir='/lib/${PROGRAMNAME}'

and so on. All docs need not be duplicated for web server, so,

APACHEDIR=/Apache
DOCDIR='${APACHEDIR}/htdocs/docs/${PROGRAMNAME}

which would put all programs' documentation under the web server, rather than in usr directories where they are probably never used and just take up a lot of space. Isn't it easier to use the Apache server to browse for a program's documents? I think so. So there is no longer any need, nor justification, for putting them under /usr/local/share/mysql/docs which takes up a whole lot more space and never gets accessed.

Some developers just don't get the power of html and httpd. Everything, as you can see, is evolving toward them and around them. Even databases, because they are much better at presenting data than old things like word processors and databases that can't talk to httpd. It's the raisin d'etre for both MySQL and PHP, the web interface to their databases.

and the use of all capitals simply shows the the new structure and its associated configure filename for the one-liner files that can be edited much more quickly than script lines in configure.

For now though, you just have to live with fixing the configure script or using options in the configure call.

Sometimes, you just have to eat the bun and not think about it.

Youch! I'll never touch Slackware then. On Rh9 they all configure, compile and install straight out of the box...

Maybe you'll consider switching distros? A ten hour investment with zero return is bad and would be unacceptable to my boss. A full dual-boot Windows / Rh9 linux install on my P4 system takes about three hours - and afterward MySQL (I use 4.0something) Php and Apache take about an hour. Four hours an I am up and running again.

Better than ten and zero results...?

It's not really the distribution that is the problem, is it? It is the program that he is trying to compile and install. I have verified that.

Pat Volkerding got sick for a little time and basically the other distribution developers left him in the dust. So did the developers. This lead to a slight lag in Slackware keeping up with new releases, but more importantly, it showed that the developers were completely and totally willing to abandon one of their oldest friends.

I continued working with Slackware because there is no doubt that is the best distribution around. And that is because it does not depend on a Microsoft oriented "out of the box" installation.

Bob Bemer said it; the blame is lazy programmers.

The second blame is lazy administrators.

What I found in trying to install new releases while Pat was out of it is that the whole structure of the Free Sourceware foundations are outdated.

You cannot justify a 3 meg configure file. You can no longer justify the same old tree structure that dates back to the original Unix, let alone Linux.

You cannot justify editing three million lines of script in an environment that is supposed to be modular and object oriented. That means, the whole approach of autoconfig, automake, libtool, configure, and make are outdated and "not" object oriented. Because source files and header files are smallish modules whose rapid compilation is immediately defeated by the use of sed scripts, bash scripts, perl scripts, and other interpretor and System Operator Command Console macroscripts used to compile and install programs.

Having things like layout files is the answer. There should also be files for every compile time option to make it faster to resolve a problem. That was the original approach and goal of object oriented and modular programming, to eliminate the massive scripts required to accomplish a compile, install, and go. It is easier to document and find an error in a single small options file, such as layout, than it is to go through three million lines of script with a cryptic error message and then fix the script. It is much simpler to change the contents of a small text file that the compile command references. Additionally, the compile can report the exact name of the file and option that failed. If a programmer cannot see this, his thinking is monolithic, just like "configure" and "make."

Object oriented means small, independent files that can be included and used without having to search through and edit a 3 meg file. There is the waste of time, it is not the fault of the distribution. The fact that latter day distributions, such as Red Hat and Debian, install "out of the box" merely means that both organizations have had enough personnel to add enough patches to make most installations work out of the box. However, they have a greater chance thereafter of exploitation thanks to all the patchwork.

Bob Bemer worked for probably the laziest boss in the world, the CEO of IBM. At the time he was the laziest, and from firsthand reports a leche as well. This boss too wanted things "out of the box," and that only lead to untrained personnel writing terrible code that caused IBM and others to wind up in costly litigation. The name of the program mostly responsible was Cobol, and Bemer was one of its original authors. In the end, that lazy boss betrayed both Bemer and his wife. So if your boss wants everything "out of the box," he is ignorant and undeserving of the trust of any computer professional. He or she is in it all for himself or herself. They will have no second thoughts about mugging you or pinching your wife near no man's land.

Bemer is the Father of ASCII, and a pioneer in computers and networking. Moreso than a lot of names that are bantered about on forums worldwide, and if he says it, I believe it, all of it. Bob Bemer is the Father of the Escape sequence; the escape key, a function so basic to all programming that the Internet would not run without it. Check Bob Bemer's site if you don't believe it.

This is a "must read" for anyone who thinks of themself as a computer or IT professional:

http://www.bobbemer.com/

And if Bob Bemer says the problem is lazy programmers, developers, and bosses, then that is the problem.

It is not the distribution.