I am using FreeBSD and have installed iconv package form port collection.I wrote
AC_CHECK_HEADER([iconv.h], ,[AC_MSG_ERROR([can not find iconv.h])])
AC_CHECK_LIB([iconv], [iconv_open], ,[AC_MSG_ERROR([can not find iconv_open])])
in the configure.ac.But when I run ./configure, it gave me the following message
checking iconv.h usability... no
checking iconv.h presence... no
checking for iconv.h... no
configure: error: can not find iconv.h
I am sure there is iconv.h, libiconv.la, libiconv.so in the directory of /usr/local/include and /usr/local/lib.So how should I write the correct statement to check the header file and library.Thanks advance!!
You should not modify your configure.ac in any way. The user is responsible for telling the tool chain where to look for libraries. For the user (which is who you are when you run configure), an easy thing to do is to set up a config.site so that the appropriate flags are set. For example, in your .bashrc: export CONFIG_SITE=$HOME/CONFIG_SITE, and then in $HOME/CONFIG_SITE, something like:
test "$prefix" = NONE && pfx=/usr/local || pfx=$prefix
: ${CPPFLAGS=-I$pfx/include}
: ${LDFLAGS=-L$pfx/lib}
This will insert appropriate flags to the compiler and linker to always look in some common locations.
Most likely the paths /usr/local/include and /usr/local/lib are not searched by default by the compiler. You can do it be modifying the CFLAGS and LDFLAGS variables in your configure.ac script:
CFLAGS="$CFLAGS -I/usr/local/include"
LDFLAGS="$LDFLAGS -L/usr/local/lib"
Add those two lines before you check for the header and library.
Possibly you might have to set CPPFLAGS (for the pre-processor) and CXXFLAGS (if you are building C++ code) as well, to add the include path.
Edit: To set these flags in configure.ac is, as noted by William Pursell, not really recommended. Instead you set the these as environment variables when invoking the generated configure script:
$ CPPFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib ./configure
There's always the AM_ICONV automake macro (iconv.m4) which is part of GNU gettext. You need not use gettext.m4.
Related
I'm developing an open source application where I'd like to include Perl conditionally (for different text processing purposes - that's just for information, not to be criticized as a concept :-). How would you normally check for availability of Perl headers using autoconf?
In my configure.ac I use the following for stuff that has pkg-config files:
PKG_CHECK_MODULES(GTK, gtk+-3.0, [AC_DEFINE([HAVE_GTK_3], 1, [Define to 1 if GTK+ 3 is present])])
PKG_CHECK_MODULES(SQLITE, sqlite3, [AC_DEFINE([HAVE_SQLITE], 1, [Define to 1 if SQLite is present])])
Unfortunately AFAIU Perl doesn't ship any .pc-s. In my Makefile.in to generate compiler flags I use their perl -MExtUtils::Embed -e ccopts -e ldopts instead of executing pkg-config.
Here rises the question - how would you do this in a prettier way?
I tried this:
AC_CHECK_HEADER([perl.h], AC_DEFINE(HAVE_PERL, 1, [Define to 1 if Perl headers are present]))
But it doesn't work unfortunately:
checking for perl.h... no
In my system (and probably much everywhere else) it's not in just /usr/include:
gforgx#shinjitsu nf $ locate perl.h | tail -n 1
/usr/lib64/perl5/CORE/perl.h
Is there at all a 'legal' way to extend search path for AC_CHECK_HEADER without using automake and AM_ macros?
So far I tried manipulating CPPFLAGS, and it's much better but still (probably due to other inclusions in perl.h):
configure: WARNING: perl.h: present but cannot be compiled
configure: WARNING: perl.h: check for missing prerequisite headers?
configure: WARNING: perl.h: see the Autoconf documentation
configure: WARNING: perl.h: section "Present But Cannot Be Compiled"
configure: WARNING: perl.h: proceeding with the compiler's result
configure: WARNING: ## ------------------------------------ ##
configure: WARNING: ## Report this to gforgx#protonmail.com ##
configure: WARNING: ## ------------------------------------ ##
checking for perl.h... no
Many thanks!
Update
Finally this works:
PERL_CPPFLAGS=`perl -MExtUtils::Embed -e ccopts`
PERL_LIBS=`perl -MExtUtils::Embed -e ldopts`
old_CPPFLAGS="$CPPFLAGS"
old_LIBS="$LIBS"
CPPFLAGS="$CPPFLAGS $PERL_CPPFLAGS"
LIBS="$LIBS $PERL_LIBS"
# TODO: figure out why first option doesn't work
#AC_CHECK_HEADER([perl.h], AC_DEFINE(HAVE_PERL, 1, [Define to 1 if Perl headers are present]))
AC_CHECK_FUNCS(perl_construct, AC_DEFINE(HAVE_PERL, 1, [Define to 1 if Perl headers are present]))
CPPFLAGS="$old_CPPFLAGS"
LIBS="$old_LIBS"
Not much of an autoconf expert, but I think: you can put plain shell snippets like
PERL_CFLAGS=`perl -MExtUtils::Embed -e ccopts`
PERL_LDFLAGS=`perl -MExtUtils::Embed -e ldopts`
into your configure.ac. Probably the right way to do it is to use AC_ARG_WITH to let the user specify those vars, and only get them from EU::E if the user hasn't overridden them. (likewise you can use one to have --with-perl override the HAS_PERL check entirely).
Then you can use AC_SUBST to make the values from configure-time available in the Makefile (so you don't need to call EU::E in Makefile.in).
And finally, the heart of the issue, I don't think there's a nice way to make AC_CHECK_HEADER aware that it needs some nonstandard flags, but you can do
old_CFLAGS="${CFLAGS}"
CFLAGS="${PERL_CFLAGS}"
AC_CHECK_HEADER(...)
CFLAGS="${old_CFLAGS}"
to run AC_CHECK_HEADER with PERL_CFLAGS in effect.
Note that you need Perl's C header(s) only if you want to build a Perl extension or embed a Perl interpreter in your binary. The latter seems more likely to be what you have in mind, but in that case, do consider whether it would work as well or better to simply use an external Perl interpreter, launched programmatically by your application at need. Use of an external Perl interpreter would not involve the C header at all.
However, you seem already committed to binary integration with Perl. In that case, configure is the right place to test for the availability and location of Perl's development headers, and to determine the appropriate compilation and linker flags. Putting it there also gives you the ability to use Automake conditionals to help you configure for and manage both with-Perl and without-Perl builds, if you should want to do that.
To that end, even though Autoconf does not provide built in macros for Perl detection / configuration, the Autoconf Archive has a few of them. In particular, ax_perl_ext_flags self describes its behavior as ...
Fetches the linker flags and C compiler flags for compiling and linking programs that embed a Perl interpreter.
... which I take to be appropriate for your purposes. After adding that macro to your project, you might incorporate it into your configure.ac like so:
PERL_CFLAGS=
PERL_LDFLAGS=
AX_PERL_EXT_FLAGS([PERL_CFLAGS], [PERL_LDFLAGS])
# ...
AC_SUBST([PERL_CFLAGS])
AC_SUBST([PERL_LDFLAGS])
That macro uses a technique similar to what you describe doing in your Makefile.in, but in a rather more robust way.
As for checking on the header, once you have the appropriate C compiler flags for Perl, you put those into effect (just) for the scope of the header check. This is necessary because configure uses the compiler to test for the presence of the header, and if the compiler requires extra options (say an -I option) to find the header at compile time, then it will need the same at configuration time. Something like this, then:
CFLAGS_SAVE=$CFLAGS
# Prepend the Perl CFLAGS to any user-specified CFLAGS
CFLAGS="${PERL_CFLAGS} ${CFLAGS}"
# This will automatically define HAVE_PERL_H if the header is found:
AC_CHECK_HEADERS([perl.h])
# Restore the user-specified CFLAGS
CFLAGS=$CFLAGS_SAVE
I'm bundling a .cpp program that depends on libxml, but g++ cannot find it. I've done the appropriate steps to make libxml available, however the directory structure is slightly different than the source expects. I want to know about nix-based solutions to this problem.
The compiler (from a nix-shell session) says that libxml is not in my system path:
fatal error: libxml/encoding.h: No such file or directory
#include <libxml/encoding.h>
However, it should be. In my .nix file I made sure to included libxml2
buildInputs = [ ... libxml2 ...];
and my nix-shell environment confirms that the library is present:
NIX_CFLAGS_COMPILE= [...] -isystem /nix/store/zf1nyqyx2zd6y944ln2rxnhd5m4265n4-libxml2-2.9.9-dev/include [...]
If I look in that directory, I find the search path is off. The path to the file is actually (relative to NIX_CFLAGS_COMPILE path):
libxml2/libxml/encoding.h
I found that I can compensate for this off-by-one path error by adding the following option to my compile command:
-isystem /nix/store/zf1nyqyx2zd6y944ln2rxnhd5m4265n4-libxml2-2.9.9-dev/include/libxml2
(The same path as the NIX_CFLAGS_COMPILE, but starting at the libxml2 directory.)
Given that information, I am wondering about a nix-based solution to this problem. The source is not mine, so changing them is the last thing I want to do. I see two other options.
First, I could add the path in the makefile that is triggered during buildPhase. However, I'm not exactly sure how to simply grab that path. For instance, inheriting libxml2 in my derivation makes the libxm2-2.9.9-bin directory available, when I need the libxml2-2.9.9-dev. I suppose I could grep or sed on the NIX_CFLAGS_COMPILE path, but I'd rather not.
My preferred solution would be to make a simple libxml derivation based off the libxml2 and just add that to my buildInputs, but that seems like it might not be simple either.
Try running pkg-config --cflags libxml-2.0 to get the appropriate compiler options.
If everything is configured correctly, it will find the appropriate /nix/store/*-libxml2-2.9.9-dev/lib/pkgconfig/libxml-2.0.pc file on your computer, and extract the needed compiler options from that.
You could invoke GCC using a one-liner like this:
g++ program.cpp $(pkg-config --libs --cflags libxml-2.0) -o program
This is a general solution that doesn't just apply to Nix, but you should be able to get it to work in Nix by ensuring you have the pkg-config utility on your PATH and ensuring the proper environment variables are set so that it can find libxml2. Nix probably has a bunch of shell scripts or something to help you set up your environment in that way, because this is a common need.
I solved this by defining a libxml attribute in my derivation and adding that to my buildInputs. The new library is just a link to the old, but with path corrected for. Here's the relevant parts of the derivation:
{ stdenv, libxml2, ... } : stdenv.mkDerivation
rec
{ buildInputs = [ libxml ];
libxml = stdenv.mkDerivation {
name = "libxml" ;
system = builtins.currentSystem;
outputs = [ "bin" "dev" "out" ];
phases = ["buildPhase"];
buildPhase =
''echo "my command out = $out"
echo ${libxml2.dev}
mkdir -p $out
mkdir -p $dev
mkdir -p $bin
ln -s ${libxml2.dev}/include/libxml2 $dev/include
ln -s ${libxml2.dev}/lib $dev/lib
''; };
}
I have problems with GCC and I would like to use the -l flags in a customized way.
I would like to specify the search path for the correspondant libfoo specified by -lfoo , I also would like to override any internal search path in GCC, i don't want GCC to use any random lib that can solve the symbols, I only want GCC to compile with a really specific lib when -l is specified.
I know that there are utils such as pkg-config but my problem is more gcc-centric because i'm focusing on having more control on the compilation steps.
There is an undocumented syntax for specifying an absolute lib path to gcc:
$ gcc -o test test.c -l:/usr/lib/libfoo.so #(note the colon)
See here: https://code.ros.org/lurker/message/20130119.001059.fad11362.de.html
A more standard way to do this would simply be:
$ gcc -o test test.c /usr/lib/libfoo.so
Really, the only reason to use the -l: syntax is if you have a conflicting library of the same name in your search path and you can't change the search path.
While trying to compile the latest version of the apache web server(2.4.3) on my Mac (10.8) I run into a problem. When I run the ./configure command I got the following output:
checking for chosen layout... Apache
checking for working mkdir -p... yes
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking build system type... x86_64-apple-darwin12.0.0
checking host system type... x86_64-apple-darwin12.0.0
checking target system type... x86_64-apple-darwin12.0.0
configure:
configure: Configuring Apache Portable Runtime library...
configure:
checking for APR... yes
setting CC to "/Applications/Xcode.app/Contents/Developer/Toolchains/OSX10.8.xctoolchain/usr/bin/cc"
setting CPP to "/Applications/Xcode.app/Contents/Developer/Toolchains/OSX10.8.xctoolchain/usr/bin/cc -E"
setting CFLAGS to " "
setting CPPFLAGS to " -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK"
setting LDFLAGS to " "
configure:
configure: Configuring Apache Portable Runtime Utility library...
configure:
checking for APR-util... yes
checking for gcc... /Applications/Xcode.app/Contents/Developer/Toolchains/OSX10.8.xctoolchain/usr/bin/cc
checking whether the C compiler works... no
configure: error: in `/Users/cti/Downloads/Applications/httpd-2.4.3':
configure: error: C compiler cannot create executables
See `config.log' for more details
Here are the last few lines in the log file:
## ----------- ##
## Core tests. ##
## ----------- ##
configure:3056: checking for chosen layout
configure:3058: result: Apache
configure:3861: checking for working mkdir -p
configure:3877: result: yes
configure:3886: checking for grep that handles long lines and -e
configure:3944: result: /usr/bin/grep
configure:3949: checking for egrep
configure:4011: result: /usr/bin/grep -E
configure:4027: checking build system type
configure:4041: result: x86_64-apple-darwin12.0.0
configure:4061: checking host system type
configure:4074: result: x86_64-apple-darwin12.0.0
configure:4094: checking target system type
configure:4107: result: x86_64-apple-darwin12.0.0
configure:4137:
configure:4139: Configuring Apache Portable Runtime library...
configure:4141:
configure:4182: checking for APR
configure:4327: result: yes
configure:4587:
configure:4589: Configuring Apache Portable Runtime Utility library...
configure:4591:
configure:4628: checking for APR-util
configure:4707: result: yes
configure:4968: checking for gcc
configure:4995: result: /Applications/Xcode.app/Contents/Developer/Toolchains/OSX10.8.xctoolchain/usr/bin/cc
configure:5224: checking for C compiler version
configure:5233: /Applications/Xcode.app/Contents/Developer/Toolchains/OSX10.8.xctoolchain/usr/bin/cc --version >&5
./configure: line 5235: /Applications/Xcode.app/Contents/Developer/Toolchains/OSX10.8.xctoolchain/usr/bin/cc: No such file or directory
configure:5244: $? = 127
configure:5233: /Applications/Xcode.app/Contents/Developer/Toolchains/OSX10.8.xctoolchain/usr/bin/cc -v >&5
./configure: line 5235: /Applications/Xcode.app/Contents/Developer/Toolchains/OSX10.8.xctoolchain/usr/bin/cc: No such file or directory
configure:5244: $? = 127
configure:5233: /Applications/Xcode.app/Contents/Developer/Toolchains/OSX10.8.xctoolchain/usr/bin/cc -V >&5
./configure: line 5235: /Applications/Xcode.app/Contents/Developer/Toolchains/OSX10.8.xctoolchain/usr/bin/cc: No such file or directory
configure:5244: $? = 127
configure:5233: /Applications/Xcode.app/Contents/Developer/Toolchains/OSX10.8.xctoolchain/usr/bin/cc -qversion >&5
./configure: line 5235: /Applications/Xcode.app/Contents/Developer/Toolchains/OSX10.8.xctoolchain/usr/bin/cc: No such file or directory
configure:5244: $? = 127
configure:5264: checking whether the C compiler works
configure:5286: /Applications/Xcode.app/Contents/Developer/Toolchains/OSX10.8.xctoolchain/usr/bin/cc -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK conftest.c >&5
./configure: line 5288: /Applications/Xcode.app/Contents/Developer/Toolchains/OSX10.8.xctoolchain/usr/bin/cc: No such file or directory
configure:5290: $? = 127
configure:5328: result: no
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL ""
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
configure:5333: error: in `/Users/cti/Downloads/Applications/httpd-2.4.3':
configure:5335: error: C compiler cannot create executables
See `config.log' for more details
As you can see in the log output the script in ./configure couldn't find the path to my C compiler because it's in /Applications/Xcode.app/Contents/Developer/usr/bin/cc and not in /Applications/Xcode.app/Contents/Developer/Toolchains/OSX10.8.xctoolchain/usr/bin/ccas it's stated in the log output
You may say that the solution is simple all I have to do is to modify the configure script, right?? well the problem with that is that I know nothing about shell script which is why I've been struggling with it for the last 3 hours.
Help please. Thanks in advance.
I was just struggling with a similar issue in this post I created and answered so I thought I would share my findings. Simply create the symlink by doing this:
# Create a symlink to default Xcode toolchain for OS X lion
sudo ln -s \
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain \
/Applications/Xcode.app/Contents/Developer/Toolchains/OSX10.8.xctoolchain
# Create a symlink to default Xcode toolchain for OS X maverick
sudo ln -s \
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain \
/Applications/Xcode.app/Contents/Developer/Toolchains/OSX10.9.xctoolchain
and you should at least get to the next step.
For OSX 10.9 Mavericks Apache is already installed, you can directly go to the terminal and type in the following commands
To Find the Apache Version
httpd -v
To start :
sudo apachectl start
To stop :
sudo apachectl stop
To restart :
sudo apachectl restart
I'm on OSX Mavericks and was trying to compile Apache 2.2.24 and ran into this error. I saw from other answers that the problem was with apxr and thus APR returning the wrong location for gcc. Apple supplies this and the Apache config was using the Apple supplied one.
On a whim, I looked and saw that the configure script has an option to ignore the system supplied APRs and use its own.
So I did this:
./configure --with-included-apr
And it got past the configure step and compiled without errors.
checking for gcc... /Applications/Xcode.app/Contents/Developer/Toolchains/OSX10.8.xctoolchain/usr/bin/cc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether /Applications/Xcode.app/Contents/Developer/Toolchains/OSX10.8.xctoolchain/usr/bin/cc accepts -g... yes
checking for /Applications/Xcode.app/Contents/Developer/Toolchains/OSX10.8.xctoolchain/usr/bin/cc option to accept ISO C89... none needed
checking how to run the C preprocessor... /Applications/Xcode.app/Contents/Developer/Toolchains/OSX10.8.xctoolchain/usr/bin/cc -E
checking for /Applications/Xcode.app/Contents/Developer/Toolchains/OSX10.8.xctoolchain/usr/bin/cc option to accept ISO C99... none needed
checking for pcre-config... false
configure: error: pcre-config for libpcre not found. PCRE is required and available from http://pcre.org/
====
I've downloaded the pcre-config, ran: ./configure;make;make install
and now..... Tcharammmm! Httpd apache full installed :D
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.
Ran into same issue, on Mac OS X 10.9 (Mavericks); yes as user3097424 states, Apache is pre-installed for Mavericks users, though for me, version 2.2. Therefore, needing to upgrade to 2.4, do as Adrian Rodriguez says and create a symlink, replacing '10.8' with '10.9':
sudo ln -s /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain /Applications/Xcode.app/Contents/Developer/Toolchains/OSX10.9.xctoolchain
Instead of creating a symlink, you could just add the path to your library path, just use the appropriate directories to your OSX Version.
So, in your case, it may look like
[user#host ~]$ sudo vi /etc/paths
/usr/bin
/Applications/Xcode.app/Contents/Developer/usr/bin
/Applications/Xcode.app/Contents/Developer/Toolchains/OSX10.8.xctoolchain/usr/bin
/bin
...
I think this approach is a bit cleaner without having to add symlinks in different places as expected by different tools.
Anyway, this is just an alternate solution.
Hope this helps.
#AlphaZygma this worked great for me. I'm on 10.8.5 and had to add the following to /etc/paths:
/Applications/Xcode.app/Contents/Developer/usr/bin
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
instead of yours.
Complete solution that allowed me to pass through:
checking for gcc... /Applications/Xcode.app/Contents/Developer/Toolchains/OSX10.8.xctoolchain/usr/bin/cc
checking whether the C compiler works... no
issue can be found here:
http://mac-dev-env.patrickbougie.com/apache/
The command are (some needs sudo su):
cd /usr/local/src (mkdir /usr/local/srt if /usr/local/src doesnt exist)
curl --remote-name http://mirror.csclub.uwaterloo.ca/apache/httpd/httpd-2.4.9.tar.gz
tar -xzvf httpd-2.4.9.tar.gz
rmhttpd-2.4.9.tar.gz
cd httpd-2.4.9
sudo xcode-select -switch /
mkdir -p /Applications/Xcode.app/Contents/Developer/Toolchains/OSX10.9.xctoolchain/usr/bin (this might require sudo su)
ln -s /usr/bin/cc /Applications/Xcode.app/Contents/Developer/Toolchains/OSX10.9.xctoolchain/usr/bin/cc (this might require sudo su)
./configure --prefix=/usr/local/apache-2.4.9
make
make install
ln -s apache-2.4.9 /usr/local/apache
I just recently updated to Mavericks and was re-creating my web development environment (including installing port). I had this problem when I was upgrading port:
checking whether the C compiler works... no
I thought I had everything setup, including installing XCode from the App Store. But kept having issues. I was able to fix it by actually running XCode once, accepting the license agreement, and letting XCode startup fully. The next time I tried to upgrade port I did not get the error above.
UPDATE: First problem solved, second one described at the bottom of this post.
UPDATE2: Second problem solved as well.
I'm trying to learn about setting up GNU build tools (autoconf/automake) for a very simple GTK+2 C application. I've followed this tutorial and this one that deals with sub directories, but I'm running into a problem where my source directory (in the src sub-directory) is not generating a Makefile, though the parent directory's Makefile is getting generated.
First, here is my folder structure:
app/src
- main.c
- main.h
- Makefile.am
app
- configure.ac
- Makefile.am
- aclocal.m4
(... other generated files ...)
Here are the contents of the important files:
app/configure.ac:
AC_PREREQ([2.63])
AC_INIT(app, 0.1)
AM_INIT_AUTOMAKE(app, 0.1)
AC_CONFIG_SRCDIR([src/main.h])
AC_CONFIG_HEADERS([config.h])
# Checks for programs.
AC_PROG_CC
# Checks for libraries.
# Checks for header files.
# Checks for typedefs, structures, and compiler characteristics.
# Checks for library functions.
AC_CONFIG_FILES([Makefile], [src/Makefile])
AC_OUTPUT
app/Makefile.am:
SUBDIRS = src
app/src/Makefile.am:
bin_PROGRAMS = app
app_SOURCES = main.c
app_LDADD = `pkg-config --cflags --libs gtk+-2.0`
Here is what happens when I run the following commands:
$ autoconf
$ automake -a
$ ./configure
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... none
configure: creating ./config.status
config.status: creating Makefile
./config.status: line 1153: src/Makefile: No such file or directory
config.status: creating config.h
config.status: config.h is unchanged
config.status: executing depfiles commands
When I check, the main app folder gets a Makefile and Makefile.in, but the src folder still only has the Makefile.am. Any ideas?
UPDATE: I made the changes mentioned by adl, namely, I removed the square brackets and comma from the AC_CONFIG_FILES command and removed the app name/version from the AM_INIT_AUTOMAKE command. I also changed the app_LDADD command in src/Makefile.am to app_LDFLAGS. This has fixed my initial problem of not getting through a configure, but now it isn't looking for the gtk libraries. When I do a make I get something like the following:
$ make
make all-recursive
make[1]: Entering directory `/home/adam/Development/app-0.1'
Making all in src
make[2]: Entering directory `/home/adam/Development/app-0.1/src'
if gcc -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -MT main.o -MD -MP -MF ".deps/main.Tpo" \
-c -o main.o `test -f 'main.c' || echo './'`main.c; \
then mv -f ".deps/main.Tpo" ".deps/main.Po"; \
else rm -f ".deps/main.Tpo"; exit 1; \
fi
main.c:3:21: error: gtk/gtk.h: No such file or directory
In file included from main.c:4:
main.h:4: error: expected specifier-qualifier-list before ‘GtkWidget’
Here is what I get with pkg-config:
$ pkg-config --libs --cflags gtk+-2.0
-D_REENTRANT -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lgio-2.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lglib-2.0
I'm pretty sure I'm doing something wrong in my src/Makefile.am, but I don't know what. If it helps, my configure script does not appear to be looking for any gtk libs.
UPDATE2:
So the basic solution for the problem in update1 seems to be that I needed to add the following check to my configure.ac file:
PKG_CHECK_MODULES(GTK, [gtk+-2.0 >= 2.12])
PACKAGE_CFLAGS="-g -Wall $GTK_CFLAGS"
PACKAGE_LIBS="-g $GTK_LIBS"
PACKAGE_LDFLAGS="-export-dynamic $GTK_LDFLAGS"
AC_SUBST([PACKAGE_CFLAGS])
AC_SUBST([PACKAGE_LIBS])
AC_SUBST([PACKAGE_LDFLAGS])
This gets added to the checks for programs section under AC_PROG_CC. What this does is tell configure to check for the gtk+-2.0 library. The upper case GTK seems to be an arbitrary variable name, and the CFLAGS, LIBS, and LDFLAGS (and probably more) gets added to it dynamically so that you can generate the PACKAGE_* variables. The AC_SUBST seems to make it so you can access the PACKAGE* variables in your Makefile.am's. FYI, the -export-dynamic flag is added so that you can use glade/gtkbuilder files (I'm sure there are other reasons, but I'm still at a very basic level of understanding).
In src/Makefile.am, you should have:
bin_PROGRAMS = app
app_SOURCES = main.c main.h
app_LDADD = #PACKAGE_LIBS#
app_LDFLAGS = #PACKAGE_LDFLAGS#
INCLUDES = #PACKAGE_CFLAGS#
This seems to be all you need for a basic gtk+-2.0 C app. It has actually inspired me to write a simple tutorial for setting up a C gtk app that uses autotools. There is a definite lack of recent beginner documentation/information in this field.
Two issues in your configure.ac file. First, the syntax of your AM_INIT_AUTOMAKE invocation is 10 year old, I suspect you copied it from a very old tutorial (hint: the Automake manual has a tutorialish introduction). You've already passed the package and version to AC_INIT, there is no need to repeat that in AM_INIT_AUTOMAKE. Second, the list of files passed to AC_CONFIG_OUTPUT should be a space-separated list given as first argument.
In other words, your configure.ac should look like
AC_PREREQ([2.63])
AC_INIT([app], [0.1], [your#email])
AM_INIT_AUTOMAKE([-Wall])
AC_CONFIG_SRCDIR([src/main.h])
AC_CONFIG_HEADERS([config.h])
AC_PROG_CC
AC_CONFIG_FILES([Makefile src/Makefile])
AC_OUTPUT
Note there is no coma on the AC_CONFIG_FILES line.
The -Wall option will cause automake to output more warnings (this really is an automake option, not a gcc option), it's probably safer if you discover these tools.
This should fix your configure problem. Then I suspect you'll probably have to split your app_LDADD line into app_CPPFLAGS and app_LDFLAGS.
A few more issues that haven't been mentioned yet:
Use autoreconf to (re)generate configure and Makefile.in. It calls the requisite tools in the correct order.
Prefer using the make macros (“$(FOO)”) to the Autoconf substitutions (“#FOO#”) in your makefile. The advantage of the former is that they can be overridden at make time should that be necessary.
I'd encourage you to create a separate build directory and run configure there rather than building in the source directories. This is a setup that you probably don't want to break; and if you aren't testing it, you can inadvertently break it.
Rather than adding GTK_CFLAGS and GTK_LDFLAGS to your PACKAGE_CFLAGS, you can simply do:
app_LDADD = #PACKAGE_LIBS# #GTK_LIBS#
or, if every app depends on gtk, just do
LDADD = #GTK_LIBS#
Specifying -g and -Wall the way you are is not really a good thing. You can do it more easily by defining AM_CFLAGS, and while that's fine for -Wall, you really don't want -g in there. The default configure will add -g to CFLAGS, and if the user overrides CFLAGS when configure is run, you should trust them to know what they're doing and give them the freedom to skip -g. If you are adding -g for your own convenience (so you don't need to specify -g when you specify CFLAGS at configure time), it would be more appropriate to use a CONFIG_SITE rather than hardcoding the -g in you project's build files.
Another option for this could be the following:
AM_PATH_GTK_2_0([Min version], [Succes], [Failure])
AM_PATH_GLIB_2_0([Min version], [Succes], [Failure])
It's always a good idea to take a look at what your aclocal directory (/usr/aclocal) holds as macro possibilities. Also don't forget to run aclocal so that the required M4 macros gets copied to aclocal.m4.