OSX Yosemite (10.10.5):
The accepted answer worked for me:
$ cd /Applications/Xcode.app/Contents/Developer/Toolchains
$ ln -s XcodeDefault.xctoolchain/ OSX10.10.xctoolchain
^ ^
| |
existing dir(or file) link name
(Explanation of why that works below.)
Then:
httpd-2.4.18$ ./configure (php may require an additional option)
If you are also going to install php, you may need to add another option to ./configure.
The basic instructions for installing php on Unix also give instructions on how to install apache:
./configure --enable-so
make
make install
Apache's configuration help says this:
httpd-2.4.18$ ./configure --help
...
...
--enable-so DSO capability. This module will be automatically
enabled unless you build all modules statically.
That seems to indicate that the --enable-so option might be a default option, but the apache install instructions do not even mention --enable-so. In the apache 2.2 docs for configure, I found this:
Modules, disabled by default
Some modules are compiled by default and have to be enabled explicitly...
...
...
--enable-so
...
The apache 2.4 docs for configure do not mention --enable-so. Instead, they tell you to look at the output of ./configure --help under Optional features, which lists --enable-so.
As a result, I think you should configure apache like this:
httpd-2.4.18$ ./configure --enable-so
========
INSTALLING PHP
In order to get mysql to work with php, I had to reinstall php and change the following line in the php install docs:
php-7.0.2$ ./configure --with-apxs2=/usr/local/apache2/bin/apxs --with-mysql
to:
php-7.0.2$ ./configure --with-apxs2=/usr/local/apache2/bin/apxs --with-pdo-mysql
With the first one, the configure output said that the --with-mysql option doesn’t exist--otherwise php installed fine, and php files in apache's htdocs directory were executed by php.
The problem is that php has changed its mysql support, and mysql_connect() is deprecated(and removed from php7), so now you need the pdo-mysql adapter, as described in the php docs.
After reinstalling php, the last lines of make install said this:
You may want to add: /usr/local/lib/php to your php.ini include_path
php.ini is located here: /usr/local/lib/php.ini, and I made that change:
include_path = ".:/php/includes:/usr/local/lib/php"
Then I restarted apache, made sure mysql was running, and I entered the following url in my browser:
http://localhost:8080/mysql_test.php
and my test PDO script worked (located in the directory /usr/local/apache2/htdocs):
<?php
$user = 'root';
$password = ’root_password_here’;
$host = 'localhost';
$dbname = 'my_db';
$pdo = new PDO(
"mysql:host=$host; dbname=$dbname",
$user,
$password
);
$statement = $pdo->query("SELECT 'Hello, dear MySQL user!' AS _message FROM DUAL");
$row = $statement->fetch(PDO::FETCH_ASSOC);
echo htmlentities($row['_message']);
?>
===========
After getting the same error message as the op, I checked config.log in the httpd-2.4.18 directory, and a line in there says:
./configure: line 5326: /Applications/Xcode.app/Contents/Developer/Toolchains/
OSX10.10.xctoolchain/usr/bin/cc:
No such file or directory
So the configure script is looking for:
A directory named:
/Applications/Xcode.app/Contents/Developer/
Toolchains/OSX10.10.xctoolchain/usr/bin/
A file named cc in that directory.
Okay, let's see if cc is in that directory:
~$ cd/Applications/Xcode.app/Contents/Developer/Toolchains/
OSX10.10.xctoolchain/usr/bin/
-bash: cd: /Applications/Xcode.app/Contents/Developer/Toolchains/
OSX10.10.xctoolchain/usr/bin/: No such file or directory
That means the directory does not exist. Now you have to figure out which directory in that long path is the one that doesn't exist:
~$ cd /Applications/Xcode.app
/Applications/Xcode.app$ cd Contents/Developer
/Applications/Xcode.app/Contents/Developer$ cd Toolchains/OSX10.10.xctoolchain
-bash: cd: Toolchains/OSX10.10.xctoolchain/: No such file or directory
/Applications/Xcode.app/Contents/Developer$ cd Toolchains
/Applications/Xcode.app/Contents/Developer/Toolchains$ ls
XcodeDefault.xctoolchain
You can see that there is no directory named OSX10.10.xctoolchain--there is only a directory named XcodeDefault.xctoolchain. As a result, the configure script can't locate the directory OSX10.10.xctoolchain in the path that it is using to find the cc file. Why is configure looking for that directory? Because either the dev who wrote the script screwed up or Apple screwed up.
The real goal of configure is not to find a directory but to find the pesky cc file. It turns out that the cc file is located here:
/Applications/Xcode.app/Contents/Developer/Toolchains/
XcodeDefault.xctoolchain/usr/bin$ ls
...
cc
clang
...
...
And for the more curious:
/Applications/Xcode.app/Contents/Developer/
Toolchains/XcodeDefault.xctoolchain/usr/bin$ ls -al cc
lrwxr-xr-x 1 7stud admin 5 Oct 29 15:22 cc -> clang
cc is just a link to Xcode's clang compiler.
The accepted answer creates a link from the name OSX10.10.xctoolchain to the directory that actually contains the cc file (albeit several directories deeper) XcodeDefault.xctoolchain:
Applications/
Xcode.app/
Contents/
Developer/
Toolchains/
XcodeDefault.xctoolchain/
OSX10.10.xctoolchain/ -> XcodeDefault.xctoolchain/
usr/
bin/
cc
In other words, after creating the link the two paths:
/Applications/Xcode.app/Contents/Developer/Toolchains/
XcodeDefault.xctoolchain/usr/bin
/Applications/Xcode.app/Contents/Developer/Toolchains/
OSX10.10.xctoolchain/usr/bin
will be equivalent. The names XcodeDefault.xctoolchain and OSX10.10.xctoolchain will be aliases for the same directory.
====
I don't understand @AlphaZygma's answer. It advises adding the following two directories to your PATH (via /etc/paths):
/Applications/Xcode.app/Contents/Developer/usr/bin
/Applications/Xcode.app/Contents/Developer/Toolchains/
OSX10.8.xctoolchain/usr/bin
On my system, the first directory does not contain a cc file, so there's no reason for me to add that directory to my PATH.
The second directory is the directory that configure says it can't find. Adding a non-existent directory to your PATH still means it's non-existent.
In any case, the configure script does not seem to be searching the PATH directories for cc because the error message lists a non-exist path as the problem. How would searching the PATH directories result in the error message listing a non-existent path? The configure script seems to be getting directions from somewhere else telling it where to search for cc.
I'm not sure why @AlphaZygma inserted the new paths between some of the existing paths in /etc/paths. Why not add the new paths below the existing paths?
I tried several different versions of this answer, but nothing worked for me.
====
I looked at the output of ./configure --help:
Usage: ./configure [OPTION]... [VAR=VALUE]...
To assign environment variables (e.g., CC, CFLAGS...), specify them as
VAR=VALUE. See below for descriptions of some of the useful variables.
...
...
Some influential environment variables:
CC C compiler command
CFLAGS C compiler flags
LDFLAGS linker flags, e.g. -L<lib dir> if you have libraries in a
nonstandard directory <lib dir>
LIBS libraries to pass to the linker, e.g. -l<library>
CPPFLAGS (Objective) C/C++ preprocessor flags, e.g. -I<include dir> if
you have headers in a nonstandard directory <include dir>
CPP C preprocessor
Hey, CC is listed there. Let's try:
$ ./configure CC=/Applications/Xcode.app/Contents/Developer/
Toolchains/XcodeDefault.xctoolchain/usr/bin/cc
...
...
checking for APR... yes
setting CPP to "/Applications/Xcode.app/Contents/Developer/Toolchains/OSX10.10.xctoolchain/usr/bin/cc -E"
setting CFLAGS to " "
setting CPPFLAGS to " -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -DDARWIN_10"
setting LDFLAGS to " "
configure:
...
...
configure: error: C compiler cannot create executables
Looking at the output a little more carefully there is this line:
setting CPP to "/Applications/Xcode.app/Contents/Developer/Toolchains/
OSX10.10.xctoolchain
The configure script is still mentioning that non-existent path in conjunction with CPP. Looking at the output of ./configure --help again:
Usage: ./configure [OPTION]... [VAR=VALUE]...
To assign environment variables (e.g., CC, CFLAGS...), specify them as
VAR=VALUE. See below for descriptions of some of the useful variables.
...
...
Some influential environment variables:
CC C compiler command
CFLAGS C compiler flags
LDFLAGS linker flags, e.g. -L<lib dir> if you have libraries in a
nonstandard directory <lib dir>
LIBS libraries to pass to the linker, e.g. -l<library>
CPPFLAGS (Objective) C/C++ preprocessor flags, e.g. -I<include dir> if
you have headers in a nonstandard directory <include dir>
CPP C preprocessor
The last line lists the variable CPP, which was mentioned in the error line. Let's try:
$ ./configure \
> CC=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc \
> CPP=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc
...
...
checking how to run the C preprocessor... /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc
configure: error: in `/Users/7stud/Downloads/httpd-2.4.18':
configure: error: C preprocessor "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc" fails sanity check
See `config.log' for more details
Now all the paths are correct in the error message, but something "fails sanity check". I give up! Maybe someone else can pick up where I left off.
Okay, thanks to the suggestions here, the following works:
$ ./configure \
> CC=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc \
> CPP='/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -E'
and that can be shortened to:
$ ./configure \
> CC=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc \
> CPP='cc -E'
But then make failed:
$ make
...
/usr/share/apr-1/build-1/libtool: line 8962: /Applications/Xcode.app/Contents/Developer/Toolchains/OSX10.10.xctoolchain/usr/bin/cc: No such file or directory
Once again the non-existent path is mentioned--this time in conjunction with libtool. That's as far as I'm going down that rabbit hole.
