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.
Related
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'm trying to port libisofs to Windows. My environment is MSYS2 with mingw-w64-i686 toolchain installed.
I've used gnulib for missing headers with
gnulib-tool --import command:
$ ../gnulib/gnulib-tool --import fnmatch
I've done all steps in instruction:
Don't forget to
- add "lib/Makefile" to AC_CONFIG_FILES in ./configure.ac,
- mention "lib" in SUBDIRS in Makefile.am,
- mention "-I m4" in ACLOCAL_AMFLAGS in Makefile.am,
- mention "m4/gnulib-cache.m4" in EXTRA_DIST in Makefile.am,
- invoke gl_EARLY in ./configure.ac, right after AC_PROG_CC,
- invoke gl_INIT in ./configure.ac.
Altough, there was no AC_PROG_CC in configure.ac, so I've added gl_EARLY after AM_PROG_CC_C_O
And there was no SUBDIRS variable in Makefile.am so I've added it manually at the bottom, as so:
SUBDIRS = lib
All configurations I've made as so:
autoreconf -i
automake --add-missing
autoconf
./configure
After running make I recieve error:
hard-locale.c:19:10: fatal error: config.h: No such file or directory
#include <config.h>
As I understand that file must be created by ./configure, but I don't understand why compiler doesn't find it.
configure.ac: https://pastebin.com/JbWRqjEv
Makefile.am: https://pastebin.com/V6ZBq8Vd
All outputs: https://pastebin.com/WFu5aJU7
Gnulib assumes that your configure.ac file contains
AC_CONFIG_HEADERS([config.h])
Without it, every compiler command invocation is more than 1000 characters long, due to the many -D options; this is not practical for development.
Basic steps leading up to the question:
cd linux-2.6.35.9/
make ARCH=x86 INSTALL_HDR_PATH=${PREFIX}/${TARGET} headers_install
cd ../
cd build-binutils/
sh ../binutils-2.28/configure --prefix=${PREFIX} --target=${TARGET}
make
make install
cd ../
cd build-gcc/
sh ../gcc-4.9.4/configure --prefix=${PREFIX} --target=${TARGET} --enable-languages=c,c++ --disable-multilib
make all-gcc
make install-gcc
cd ../
The problem that I am running into is that what ends up getting installed into ${PREFIX}/lib/gcc/${TARGET}/4.9.4/include-fixed/limits.h doesn't seem to be correct. Specifically, the "fixincludes" bit in building and installing GCC is expecting some directory called "sys-include" that was never put into place and when it's not, the aforementioned limits.h doesn't reference the associated syslimits.h (in the same directory).
If I look in the output of the build/install sequence there's a reference to building this file from components limitx.h, limity.h, and some other bits. This test fails and it just installs the "generic" limits.h that came with GCC (that doesn't include a reference to syslimits.h which uses GCC's #include_next directive to include ${PREFIX}/${TARGET}/include/limits.h that has actual stuff in it I need like NAME_MAX and PATH_MAX).
The bit that is missing from the file is:
/* This administrivia gets added to the beginning of limits.h
if the system has its own version of limits.h. */
/* We use _GCC_LIMITS_H_ because we want this not to match
any macros that the system's limits.h uses for its own purposes. */
#ifndef _GCC_LIMITS_H_ /* Terminated in limity.h. */
#define _GCC_LIMITS_H_
#ifndef _LIBC_LIMITS_H_
/* Use "..." so that we find syslimits.h only in this same directory. */
#include "syslimits.h"
#endif
So is there an option I'm not passing to GCC's configuration script or that I am not passing to something ahead of this step that would create the sys-include directory properly?
[EDIT]
TARGET=i686-redhat-linux (a target triple from "gcc -dumpmachine" on a build server we use for the project)
Possibly more helpful information(?): The packages were simply "wget" pulls from respective archives. I am building on an up-to-date Ubuntu 16.04 installation where I installed libgmp-dev and libmpfr-dev to avoid having to compile them with the compiler source code.
After more digging and trial-and-error I matched up some stuff I started with How to Build a GCC Cross-Compiler with information about an apparently deprecated option --with-headers for configuring GCC. (--with-headers=${PREFIX}/${TARGET}/include/linux) That worked but when I built the compiler support library it complained about missing bits/stdio_lim.h. I found another post here that talks about this problem (you have to go up in the thread a bit) and had mentioned the touching gnu/stubs.h thing from the first page I mentioned.
Added from my own comment below to note that you have to remove the ${PREFIX}/${TARGET}/sys-include directory that gets build after the make install-gcc step or else your normal C headers are going to conflict with the Linux Kernel-specific headers that get included in the search path by default.
Suffice it to say that, after applying a patch to the older Glibc I was using (2.11.3) the entire sequence ends up something like this:
export TARGET=i686-redhat-linux
export PREFIX=$(pwd)/output
export PATH=${PATH}:${PREFIX}/bin
mkdir build-binutils
mkdir build-gcc
mkdir build-glibc
cd linux-2.6.35.9/
make ARCH=x86 INSTALL_HDR_PATH=${PREFIX}/${TARGET} headers_install
cd ../
cd build-binutils/
sh ../binutils-2.28/configure --prefix=${PREFIX} --target=${TARGET}
make
make install
cd ../
cd build-gcc/
sh ../gcc-4.9.4/configure --prefix=${PREFIX} --target=${TARGET} --enable-languages=c,c++ --disable-multilib --with-headers=${PREFIX}/${TARGET}/include/linux
make all-gcc
make install-gcc
cd ../
rm --recursive --force ${PREFIX}/${TARGET}/sys-include
cd build-glibc/
sh ../glibc-2.11.3/configure --prefix=${PREFIX}/${TARGET} --build=$(gcc -dumpmachine) --host=${TARGET} --target=${TARGET} --disable-multilib libc_cv_forced_unwind=yes libc_cv_c_cleanup=yes
make install-bootstrap-headers=yes install-headers
make csu/subdir_lib
install csu/crt1.o csu/crti.o csu/crtn.o ${PREFIX}/${TARGET}/lib
${TARGET}-gcc -nostdlib -nostartfiles -shared -x c /dev/null -o ${PREFIX}/${TARGET}/lib/libc.so
touch ${PREFIX}/${TARGET}/include/gnu/stubs.h ${PREFIX}/${TARGET}/include/bits/stdio_lim.h
cd ../
cd build-gcc/
make all-target-libgcc
make install-target-libgcc
cd ../
cd build-glibc/
make
make install
cd ../
I don't see any pages that actually go to this depth (maybe the Preshing on Programming page isn't actually totally correct?) but I am going to test this configuration and make sure the software builds completely for the target without problems. (I did test NAME_MAX from limits.h in a file and it seemed to work just fine and dandy.)
I also don't really know that I need to put in the --disable-multilib thing but that seems to be what other pages are doing. That chain in the GCC mailing list talks about using --with-newlib or --disable-shared as options but people on the thread could not agree either of those were the correct solution.
If anyone has better insight into this I sure would appreciate a less hacky, more official solution to the problem.
In case anyone was wondering, the patch (there are two) to fix Glibc 2.11.3 was one custom fix for the configure script to work with GNU Make 4+:
sed -i 's/\(3.79\)/4.* | \1/' glibc-2.11.3/configure
... and an actual patch to two files in the library to fix i686 suport:
patch glibc-2.11.3/nptl/sysdeps/pthread/pt-initfini.c <<__EOF__
## -45,6 +45,11 ##
/* Embed an #include to pull in the alignment and .end directives. */
asm ("\n#include \"defs.h\"");
+asm ("\n#if defined __i686 && defined __ASSEMBLER__");
+asm ("\n#undef __i686");
+asm ("\n#define __i686 __i686");
+asm ("\n#endif");
+
/* The initial common code ends here. */
asm ("\n/*#HEADER_ENDS*/");
__EOF__
patch glibc-2.11.3/sysdeps/unix/sysv/linux/i386/sysdep.h <<__EOF__
## -29,6 +29,10 ##
#include <dl-sysdep.h>
#include <tls.h>
+#if defined __i686 && defined __ASSEMBLER__
+#undef __i686
+#define __i686 __i686
+#endif
/* For Linux we can use the system call table in the header file
/usr/include/asm/unistd.h
__EOF__
I got that last patch from here.
I am trying to build the mali driver for linux 3.7 kernel from Here.
There is a separate build script like,
#!/bin/bash
export KDIR=/path/to/kernel/dir/
..
..
gcc -v//Just for testing purpose printing gcc version
make
gcc -v
...
Actual host machine has 2.6 kernel, but im instructing make to use linux 3.7 kernel. The above make will call the Makefile of mali driver's makefile.
For the above script,
gcc version prints properly before and after make command, but when make entered in to kernel directory, gcc is not recognized.
it saying gcc : directory : No such file or directory.
same happens to arm-gcc too. Any Guess??
Edit:(make output)
make ARCH=arm -C /home/work/linux3.7/ M=/home/work/mali/driver/src/devicedrv/mali modules
make[1] : Entering directory `/home/work/linux3.7/`
gcc : directory : No such file or directory
gcc : directory" : No such file or directory
<command-line>: warning: missing terminating " character
gcc : directory : No such file or directory
gcc : directory" : No such file or directory
<command-line>: warning: missing terminating " character
gcc : directory : No such file or directory
gcc : directory" : No such file or directory
<command-line>: warning: missing terminating " character
gcc : directory : No such file or directory
gcc : directory" : No such file or directory
<command-line>: warning: missing terminating " character
CC [M] /home/work/mali/driver/src/devicedrv/mali/common/mali_kernel_core.o
.arm-none-linux-gnueabi-gcc: directory:No such file or directory
.arm-none-linux-gnueabi-gcc: directory":No such file or directory
make[2] : Leaving directory `/home/work/linux3.7/`
The problem is in drivers/gpu/vithar/ump/src/devicedrv/Makefile.common. It assumes that the vithar SDK has been pulled from SVN and has a valid SVN revision (it doesn't).
You have 2 options:
1) Edit the file above to skip invocation of svnversion:
- SVN_REV:=$(shell ((svnversion | grep -qv exported && echo -n 'Revision: ' && svnversion) || git svn info | sed -e 's/$$$$/M/' | grep '^Revision: ' || echo ${MALI_RELEASE_NAME}) 2>/dev$
+ SVN_REV=0
2) Add to make command line:
SVN_REV=0
gcc is recognized, found, and executed. The error "gcc: directory: no such file or directory" is given by gcc itself.
For some reason, gcc is trying to access "directory" (i.e., an object called "directory"), which does not exist.
Maybe a wrong expansion or an unexpected environment variable.
Try checking the appropriate Makefile and your make command.
For example, if you issued a command such as
KDIR="/usr/Linux Kernel directory" CONFIG=pb-virtex5 BUILD=release make
there is a risk that the system misinterpret KDIR, introducing two nonexistent objects "Kernel" and "directory" as well as an extra quotation mark. Such a possibility might explain the symptoms you observe. So, extra spaces in paths are definitely something worth checking.
You made a typo; you want
echo $(gcc -v)
but actually, for that coding
gcc -v
is enough.
You should be sure that gcc is correctly installed in your $PATH. Check with which gcc
addenda
If you suspect your Makefile is wrong, use remake to debug it. Often, just running remake -x in a terminal could be enough to understand what is happening.
Perhaps you are passing some weird argument to gcc ? Or some wrong #include?
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.