Is this a typical behavior in autoconf that quotes in autotools generated defines are escaped?
Ie instead of
-DFOO="foo\ bar"
it produces
-DFOO=\"foo\ bar\"
The escaped version works fine in newer gcc but for gcc 4.5.1 it fails. Unfortunately I can not use newer gcc on this platform so I need to somehow find a way to prevent autoconf from escaping the quotes. Does anyone know how?
Related
I'm currently working on a Linux project using autotools. The code is submitted in SCM (Perforce) and we have the configure script, Makefile.am, Makefile.in - the usual autotools boilerplate. Recently, somebody has changed Makefile.am, but forgot to regenerate Makefile.in; when I tried to build, I got this error:
WARNING: `automake-1.11' is missing on your system. You should only need it if
you modified `Makefile.am', `acinclude.m4' or `configure.ac'.
You might want to install the `Automake' and `Perl' packages.
Grab them from any GNU archive site.
cd . && /bin/bash ./config.status Makefile depfiles
I see the automake version is hardcoded in the configure script (and seems to come from aclocal.m4):
am__api_version='1.11'
So I guess I need automake-1.11 (not 1.10, not anything newer) to regenerate the Makefile.in file.
Why is that? Why should we be tied to a specific automake version? We're mostly building on Ubuntu 14.04, where 1.14 is the default version installed. Is there a way to tell the build system to simply use whatever version of automake is installed? Or is it safe to maybe remove the am__api_version definition from aclocal.m4?
The problem is that you are trying to recreate Makefile.in with other version of autotools. It would lead to version mismatch as aclocal.m4 was built with different version and it is used to generate the remaining files.
Instead of recreating only Makefile.in, try to also recreate aclocal.m4 and all remaining autotools generated files:
autoreconf --force --install
The important question is why would someone fix am__api_versions.
The most probable answer is: Because automake tends to alter the macro's arguments or even remove entirely macros of previous release. In each release announcement of automake there is a section called
WARNING: Future backward-incompatibilities!
and an other one called
Obsolete features removed
You can refer to releases 1.12, 1.13, 1.14
So the configure.ac or Makefile.am might contain some macros which have become obsolete in later releases. When encountering this problem you have two possibilities. Either find out which feature replaced the obsolete one or stick to one version of automake. Most developers do not feel that autotools files are part of the projects source code. They just wish to keep the working version running and stick to the current am version.
Note that all distributions support older versions of automake. In ubuntu you can find:
$ apt-cache search automake | grep automake
automake - Tool for generating GNU Standards-compliant Makefiles
automake1.4 - A tool for generating GNU Standards-compliant Makefiles
automake1.9 - A tool for generating GNU Standards-compliant Makefiles
automake1.10 - Tool for generating GNU Standards-compliant Makefiles
automake1.11 - Tool for generating GNU Standards-compliant Makefiles
Meaning that you can install the requested version of automake.
So, you could remove the line am__api_version='1.11' and find out which macro is obsolete. Then you will have to decide which of the above two solutions you will follow.
I am running the latest version of MinGW GCC 4.7.2, and it was working fine with -std=c++11 before I installed Haskell using Haskell Platform. Please take a look at this:
For some reason, the GCC went back to 4.5.2, after installing Haskell, I re-installed it, with version 4.7.2, but its still showing 4.5.2.
Haskell adds its own GCC to your system PATH. You can check this is true by running
where gcc
which will show two commands, the Haskell one first, followed by your MinGW GCC.
The solution is to change your PATH to point to the GCC you want (but make sure Haskell still uses its GCC, I doubt it'll agree with GCC 4.7 if it came with GCC 4.5).
The easiest is to have some script ou can run to set up your compilation environment, so you don't have to worry about system PATHs.
If you don't care much about that exact GCC version you had installed, you can get my builds (32-bit and 64-bit), which come with a .cmd file you can doubleclick and it will give you a build environment much like the MSVS commandline shortcut, but for GCC. All it really does is add the compilers to PATH.
I am trying to use libfann version 2.0.1 instead of the newest version 2.2.0, but could not figure out how to do so. Any thoughts on how to do that?
normally that works perfectly:
gcc fann_calculator.c -o run_fann_calculator -lfann -lm
where fann_calculator.c contains a program that calls a neural network.
Thanks
It depends upon where the two libraries sit. If they are installed in the same directory (e.g. both installed in /usr/lib/) you'll probably get the youngest one.
I suggest to carefully read the ld.so(8) and ldd(1) man pages. You certainly can trace what library is loaded (with e.g. the LD_DEBUG envirnonment variable). Don't forget to re-run ldconfig appropriately after library installation.
You could also play some LD_LIBRARY_PATH trick; for instance, set it to $HOME/lib:/usr/lib and install appropriate symlinks in your $HOME/lib/ to the precise library you want. For instance, you might do
ln -s /usr/lib/libfann.so.2.0.1 $HOME/lib/libfann.so.2
export LD_LIBRARY_PATH=$HOME/lib:/usr/lib:/lib
then check with ldd run_fann_calculator that you get the expected [version of the] libfann library.
Don't forget to read the Program Library Howto. You might want to pass appropriate flags to ld such as -rpath. You may need to pass them using gcc, perhaps with Gcc Link Options such as -Wl
I'm trying to compile libpng & zlib using the RVCT 4.0 armcc compiler. However armcc cannot find 'fcntl.h', which I assume is a standard C library. Cygwin has fcntl.h (and the associated files types.h and _types.h), but when I use those, I get various compilation errors.
Should I be using Cygwin's version of standard C libraries, or RVCT's? If the latter is correct, where do I get RVCT's versions of fcntl.h, types.h and _types.h?
Thanks!
Arjun
Which version of zlib/libpng are you trying to compile?
fcntl.h is POSIX standard, not ANSI/ISO C. RealView doesn't care about POSIX.
Compiling the zlib with RVCT 4.0 has always worked like a breeze.
I've tried libpng: well, it works if you define RISCOS, to prevent the sources from including sys/types.h (yet another POSIX file).
Here's my command line: armcc -c *.c -I/tmp/zlib/ -DRISCOS
Hope this helps
For some reason, I should use gcc to compile a C file, then link against Visual C++ 2008 project.
(I used the current latest gcc version: cygwin gcc 4.3.4 20090804.)
But there is one problem: gcc always allocate a big array with _alloca,
and VC linker can't resolve the symbol __alloca.
for example,
int func()
{
int big[10240];
....
}
this code makes the _alloca dependency although I didn't call the _alloca function explicitly.
(array size matters. if i change 10240 -> 128, everything ok)
I tried gcc option -fno-builtin-alloca or -fno-builtin, but no luck.
Is it possible to make gcc not to use _alloca ? (or adjust the threshold?)
Best thing to do would be to compile all code with VC++. If that's not possible..
You should use the mingw gcc instead of the cygwin one. It's designed to output code that will be linked against the VC++ runtime, not the cygwin libraries. In particular, it will call the VC++ runtime function __chkstk instead of __alloca.
You could just write your own _alloca routine and link against that. Look at the gcc library source to see what it's supposed to do.
It looks like _alloca has been deprecated by Microsoft and is no longer in their runtime libraries after VS2005. Newer runtime libraries support _malloca.
Your options don't look good. You can try to build with VS2005 instead. Perhaps cygwin has an option where you can tell it you are using a newer runtime library (and if they don't support that yet, you could file it as a feature request).
some related discussions:
cygwin: gcc and alloca
GNU Compiler Collection (GCC) Internals
gcc and alloca