I am trying to build libwurfl (https://github.com/filosganga/libwurfl) on CentOS. I have installed all the dependent libraries, but I am having issues with running configure for libwurfl. I am constantly getting issues with Apache headers not found issue.
If I use --with-apxs as shown below,
./configure --with-apxs=/usr/sbin/apxs/
Output:
checking for apr.h... yes
checking httpd.h usability... no
checking httpd.h presence... no
checking for httpd.h... no
configure: error: Apache headers not found.
If I add --with-apache
./configure --with-apxs=/usr/sbin/apxs/ --with-apache=/usr/include/httpd/
Output:
checking for apxs... no
checking apr.h usability... no
checking apr.h presence... no
checking for apr.h... no
configure: error: Apache Portable Runtime headers not found.
I see headers on both locations mentioned above.
Any pointers?
Thanks!
I compiled it on Ubuntu 14.04 after installing and configuring apr-1.5.2 and httpd 2.2.31. Then I compiled it in this way:./configure --with-apache='/usr/local/apache2'
Related
I'm trying to compile gcc5.3.0 on my Raspberry Pi with latest Raspbian system image.
$ ./configure --enbale-checking=release --enable-languages=c,c++,fortran --host=arm-cortexa7_neon-linux-gnueabihf --build=arm-cortexa7_neon-linux-gnueabihf --target=arm-cortexa7_neon-linux-gnueabihf
$ make
However, the original compiler (gcc4.9) complains about not founding sys/cdefs.h when compiling libgcc.
I checked I have libc6-dev and build-essential installed.
So I used grep -R 'cdefs' /usr/include/ to search it and I found it at /usr/include/bsd/. I created the sys directory and made hard links to these headers under /usr/include/bsd/sys.
This time it gave me a more weird error,
/usr/include/stdio.h:312:8: error: unknown type name 'FILE'.
I searched this on stackoverflow, and there's a similar question, https://stackoverflow.com/a/21047237/5691005. But when I removed /usr/include/sys and /usr/include/bsd, then reinstalled libc6-dev, I cannot find sys/cdefs.h under /usr/include, and the compiler gave errors still.
I'm now totally lost. Any suggestion will be appreciated.
I had similar problem with compiling gcc-8.2. I tried to do as described here with reinstalling:
sudo apt-get --reinstall install libc6 libc6-dev
After that I was locating all missing headers:
find / -name cdefs.h
and copying them to /usr/include:
those steps allowed only to move forward but I still didn't manage to completely build gcc.
The best solution I found is to download compiled version of gcc-8.1 from:
https://solarianprogrammer.com/2017/12/07/raspberry-pi-raspbian-compiling-gcc/
I also ran into this problem when creating a containerized build environment for cross-compiled Qt applications for raspberry pi 4.
I found I needed to edit the mkspec for the linux-rasp-pi4-v3d device and add another cflag so that gcc could find the header from my Raspi sysroot that was used to cross-compile Qt.
Specifically under qtbase/mkspecs/devices/linux-rasp-pi4-v3d-g++/qmake.conf:
QMAKE_CFLAGS = -march=armv8-a -mtune=cortex-a72 -mfpu=crypto-neon-fp-armv8 -I$$[QT_SYSROOT]/usr/include/arm-linux-gnueabihf
I'm trying to merge the Mono Runtime (v 3.0.4) with a MonoMac application, but since the upgrade to 3.0.4 (from 2.10.11) this fails with the following error:
Merging Mono Runtime into app bundle
/Applications/MonoDevelop-old.app/Contents/MacOS/lib/monodevelop/AddIns/MonoDevelop.MonoMac/mmp
-nolink "-minos=10.6.6"
-o "/Users/ted/Documents/XCode/Mac/StageTimer/StageTimer/bin/Release"
-n "StageTimer"
-a "/Library/Frameworks/Mono.framework/Versions/3.0.4/lib/mono/4.0/System.dll"
-a "/Library/Frameworks/Mono.framework/Versions/3.0.4/lib/mono/4.0/System.Xml.dll"
-a "/Library/Frameworks/Mono.framework/Versions/3.0.4/lib/mono/4.0/System.Core.dll"
-a "/Library/Frameworks/Mono.framework/Versions/3.0.4/lib/mono/4.0/System.Xml.Linq.dll"
-a "/Library/Frameworks/Mono.framework/Versions/3.0.4/lib/mono/4.0/System.Drawing.dll"
-a "/Applications/MonoDevelop-old.app/Contents/MacOS/lib/monodevelop/AddIns/MonoDevelop.MonoMac/MonoMac.dll"
"/Users/ted/Documents/XCode/Mac/StageTimer/StageTimer/bin/Release/StageTimer.exe"
Process exited with code 1, command:
pkg-config --variable=prefix mono-2
Unhandled Exception: System.IO.DirectoryNotFoundException: Directory '/lib/mono/4.0' not found.
Even if I configure MonoDevelop to use Mono 2.10.11 instead of 3.0.4 it fails with the same error (and path: '/lib/mono/4.0'). Next I also tried modifying the symlink in /Library/Frameworks/Mono.framework/Versions/Current to point to 2.10.11 but still the same error & path.
Anyone with mono & pkg-config skills that knows how to configure this?
Similar issue happened to F# compiler when one tried to run it alongside Mono 3.0.4 (instead of 3.0.3). The issue boils down to a bugfix in Mono that prevents conflicting the homebrew pkg-config set up. The workaround that was adopted in F# sources was to hardcode the path to Mono's pkg-config.
You could probably get the same result as this by just overriding the environment variable PKG_CONFIG_PATH when launching MonoDevelop, this way:
PKG_CONFIG_PATH=/path/were/mono/pc/files/are/in/Mac:$PKG_CONFIG_PATH monodevelop
The exact path must be somewhere underneath /Library/Frameworks/Mono.framework/Versions/Current/ , just look out for files with .pc extension.
I am trying to build gzip for an embedded platform on a Linux machine. I downloaded the latest gzip distribution from here. Then, make requires first to run the configure program in order to tailor a Makefile for the specific target.
So I run configure and get some error messages. The problem seems to be a combination of a few things. Our compiler version is called e-gcc, so I used the following line, and got this error:
~/Projects/gzip-1.4$ ./configure CC=e-gcc
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for style of include used by make... GNU
checking for gcc... e-gcc
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... configure: error: in `/home/xyz/Projects/gzip-1.4':
configure: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details.
Obviously, C compiled programs cannot run, b/c it is cross-compiler. The message say I have to use the --host option, but the problem is that we don't really have a defined name in gcc. However, I tried:
./configure CC=e-gcc --host=epiphany
and the error received is:
configure: WARNING: If you wanted to set the --build type, don't use --host.
If a cross compiler is detected then cross compile mode will be used.
checking for a BSD-compatible install... /usr/bin/install -c
blah blah blah
checking build system type... x86_64-unknown-linux-gnu
checking host system type... Invalid configuration `epiphany': machine `epiphany' not recognized
configure: error: /bin/bash build-aux/config.sub epiphany failed
Last thing, I tried cheating and setting the host to arm as it is closest in spirit to our architecture. The configuration went much further, but eventually failed as well with the following message:
checking for GNU libc compatible realloc... no
checking for rmdir... no
configure: error: in `/home/xyz/Projects/gzip-1.4':
configure: error: Your system lacks the rmdir function.
Please report this, along with the output of "uname -a", to the
bug-coreutils#gnu.org mailing list. To continue past this point,
rerun configure with SKIP_RMDIR_CHECK=yes.
E.g., ./configure SKIP_RMDIR_CHECK=yes
See `config.log' for more details.
I am now pretty clueless on how to continue. Any suggestions?
Does the embedded platform have an environment in which a command-line gzip program makes sense? If you want to do gzip compression and decompression from software that you're writing for the embedded platform, then you should consider zlib instead.
Did you try running with the
SKIP_RMDIR_CHECK=yes
directive?
OK, Thanks, very helpful, it gave me the clues I needed.
I have gone a little further in that I now have a more correct --host string :
--host=eIII-parallella-epiphany
so I call configure as :
./configure CC=/cygdrive/[MYPATH]/Parallella/INSTALL/bin/e-gcc --host=eIII-parallella-epiphany
However you need to do a few other things, including copying the config.sub script from the epiphany sources into your own configure space. I also had to do some other edits, so that MACHOS was defined.
see : http://forums.parallella.org/viewtopic.php?f=13&t=337&p=2014#p2014 for more details.
cheers, Beau Webber
I'm failing to compiled the rabbitmq-c library on Mac OS 10.6.6
I intend to build the php-ampq extension against it.
I've tried both the latest branch of rabbitmq-c and rabbitmq-codegen according to the instructions here and the specific branches according to the instructions here.
Running autoreconf -i as per instructions I get:
glibtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and
glibtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree.
glibtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
configure.ac:12: installing `./config.sub'
configure.ac:12: required file `./ltmain.sh' not found
configure.ac:3: installing `./missing'
configure.ac:3: installing `./install-sh'
configure.ac:12: installing `./config.guess'
examples/Makefile.am: installing `./depcomp'
autoreconf: automake failed with exit status: 1
Running simply autoconf I get:
configure.ac:3: error: possibly undefined macro: AM_INIT_AUTOMAKE
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
configure.ac:12: error: possibly undefined macro: AM_PROG_LIBTOOL
configure.ac:90: error: possibly undefined macro: AM_CONDITIONAL
Most of what I can find by searching online suggests I don't have libtool or automake. I have both.
I'm afraid I'm out of my depth with autoconf, so I don't know how/where to alter configure.ac, or whether the warning is anything do with the missing ltmain.sh file.
I solved the same problem by installing pkg-config:
sudo port install pkgconfig
How can I install X-Sendfile apache module so that MAMP can use it?
I have followed these instructions to install X-Sendfile, but it didn't work (it seems like it just installed it for the default apache installation). I also tried to manually copy /usr/libexec/apache2/mod_xsendfile.so to /Applications/MAMP/Library/modules/, but that produced the following error when restarting Apache:
Cannot load /Applications/MAMP/Library/modules/mod_xsendfile.so into server: cannot create object file image or add library
naabster's answer is correct if your MAMP binary is built for the same architecture as your kernel. The problem you're having might be that MAMP is not built using the same architecture -- I have Lion running here (10.7.3) with XAMPP 1.7.3 and I just ran across the same issue you were having.
Here's how I figured out what was wrong on my system, and how I fixed it. If your issue is the same as mine, then you should be able to follow along and verify as you go.
First, here's the output of 'uname -a' to show you that what I'm running:
Darwin Tads-Mac-Pro.local 11.3.0 Darwin Kernel Version 11.3.0:
Thu Jan 12 18:47:41 PST 2012; root:xnu-1699.24.23~1/RELEASE_X86_64 x86_64
Here are the steps I took to track down the problem and fix it:
Figure out what attributes the other (working) modules had that my freshly-built xsendfile module was missing. I picked mod_headers.so as an example. The command to find that info is 'file [filename]'. I'm running this from a terminal cd'd to the /Applications/XAMPP/xamppfiles/modules directory:
file mod_headers.so
mod_headers.so: Mach-O universal binary with 2 architectures
mod_headers.so (for architecture i386): Mach-O bundle i386
mod_headers.so (for architecture ppc): Mach-O bundle ppc
As you can see, XAMPP kindly provides a universal binary that supports i386 and ppc architectures. However, because the Lion kernel is running x86_64, everything I build using apxs unless I tell it to otherwise will be x86_64.
Check the mach-o bundle type and architecture(s) supported by the module that was built with the recommended apxs build command ('sudo apxs -cia mod_xsendfile.c'). Because we're passing '-i' the apxs will install the .so into the default apache modules dir ... /usr/libexec/apache2...
file /usr/libexec/apache2/mod_xsendfile.so
/usr/libexec/apache2/mod_xsendfile.so: Mach-O 64-bit bundle x86_64
Just to double-check that this is the problem you can also look at the httpd (apache) binary:
file /Applications/XAMPP/xamppfiles/bin/httpd
/Applications/XAMPP/xamppfiles/bin/httpd: Mach-O universal binary with 2 architectures
/Applications/XAMPP/xamppfiles/bin/httpd (for architecture i386): Mach-O executable i386
/Applications/XAMPP/xamppfiles/bin/httpd (for architecture ppc): Mach-O executable ppc
Well now, that certainly will not work with an apache instance built without an x86_64 image. Trust, but verify, eh!
Now that I'm certain I understand the issue, let's re-build the .so with the proper architecture forced on the apxs command line. To do that I'm just adding two new params, Wl (linker flags) and Wc (compiler flags). The -i means 'install' (move .so into the modules directory) and the -a means 'activate' (add or re-enable LoadModule line in the httpd.conf)
sudo apxs -cia -Wl,"-arch i386" -Wc,"-arch i386" mod_xsendfile.c
re-check that our new .so supports an architecture that matches the Apache installed (i386, not x86_64)
file /Applications/XAMPP/xamppfiles/modules/mod_xsendfile.so
/Applications/XAMPP/xamppfiles/modules/mod_xsendfile.so: Mach-O bundle i386
Awesome. Now then, copy this turkey into the XAMPP install dir:
sudo cp /usr/libexec/apache2/mod_xsendfile.so /Applications/XAMPP/xamppfiles/modules/
And add the LoadModule line to the /Applications/XAMPP/xamppfiles/etc/httpd.conf.
LoadModule xsendfile_module modules/mod_xsendfile.so
You should be able to fire up the server using either the UI or the apachectl script found in the xamppfiles/bin directory.
Hope that helps you.
Also, I did a pretty decent due-diligence search and found just about squat looking for 'XAMPP X-SendFile cannot create object' in the Goog. What I did find was your question here, once I eliminated the 'XAMPP' since I was searching for 'XAMPP', not 'MAMP'
I started out with the 'x'AMP stack something like 10 years back using LAMPP, then WAMPP but the ApacheFriends guys call theirs XAMPP now for all of the platforms they support. I prefer using theirs since I know if I have to set up on a Windows server I can just download the same package that I use now but for Windows and I can expect to find all of the same servers installed without (too many) surprises.
So, just to be (very) thorough, the other way to discover these types of problems more easily is via Console.app. Open that up, filter on org.apache.httpd and you should see something similar to this:
httpd: Syntax error on line 117 of /private/etc/apache2/httpd.conf: Cannot load
/usr/libexec/apache2/mod_xsendfile.so into server:
dlopen(/usr/libexec/apache2/mod_xsendfile.so, 10): no suitable image found.
Did find:\n\t/usr/libexec/apache2/mod_xsendfile.so: mach-o, but wrong architecture
You can also get that from a command line when you start the apache server manually:
sudo apachectl -E /tmp/foo.txt -k start; tail -f /tmp/foo.txt
This worked for me:
Install mod_xsendfile according to this for the default OsX Apache server.
copy /usr/libexec/apache2/mod_xsendfile.so to /Applications/MAMP/Library/modules/
Edit the Mamp httpd.conf file and add this line: LoadModule xsendfile_module modules/mod_xsendfile.so
Restart Mamp