I have a customer's site that is failing to install. The root of the problem is that the variable MKDIR_P is never expanded. After looking around, it appears that this is a tricky problem that rears its head in different versions of autotools, although this site has autoconf 2.69, and none of the sample problems (and solutions) I could find were with versions that recent. Does anyone out there know how to write a solution that is portable or at least somewhat portable with respect to different versions of autotools?
This should not be necessary, but you should be able to simply define it at configure time:
./configure MKDIR_P='mkdir -p'
Apparently, there is a bug in the version of automake that ships with SLES 11 SP2 (1.10.1). Downgrading automake solved the problem although I don't remember what version the site went to. The problem doesn't continue into later versions of automake, so upgrading further should also solve the problem.
Related
I have Unison 2.40.63 on both Windows and RHEL, all configs are working fine except when I try to run it first time it gives
Fatal error: Internal error: New archives are not identical.
Retaining original archives. Please run Unison again to bring them up to date.
First, just to cover our bases, I would check to make sure the same version of Unison is getting called on each machine. Unison 2.40.63 may be installed on both machines, but maybe there is a different version hiding in the PATH being called first. See unison -version.
That's probably not the issue though. This was a bug that cropped up before using older versions of Unison. See here and here. If I understand right it's because the versions of Unison were compiled with different versions of OCaml. Anyways:
There are much newer versions of Unison available. Unless you have a good reason to, I would upgrade. I'll bet this will solve your problem.
If you really really want version 2.40.63, then on each machine you'll have to first compile and install OCaml 3.12.1 from source, and then compile Unison 2.40.63 from source with OCaml and install it. This is what I had to do awhile ago to get things working with this version of Unison.
I am trying to build Firefox OS 2.2 on Ubuntu 14.04, but I keep running into an error that reads:
configure: error: Only GCC 4.6 or newer supported
*** Fix above errors and then restart with\
"make -f client.mk build"
> Build failed! <
This would normally lead me to suspect I might need GCC 4.6, but I am already using that. I have successfully built 2.0 and 2.1 on this machine in the past, and 1.1-1.4 previously on one of the '13 versions of Ubuntu before that, and I have had export CC=gcc-4.6 and export CXX=g++-4.6 in .profile practically since I installed 14.04 on this machine.
To see if I could spot anything obvious in the output I tee'd it to a file, and it is taking a good 7000 lines of output to reach the point where suddenly it thinks I am using a different gcc. If I change CC and CXX to not specify the version then it complains a lot sooner, so I take that to suggest that it is finding the right version for quite a while before complaining about this?
In any case, I am not finding anything else quite like this, and my experience with building mobile OSes is admittedly limited (only Firefox OS builds) but up until now the instructions have either worked or produced errors I could find someone else posting about already. Hopefully someone else happens to know something about why gcc-4.6 would give an error about needing version 4.6?
Edit
Turns out, there is a Bugzilla Bug Report (1121600) that mentions this. If I get the general sense of what it says, I think there is some kind of configuration thing wrong that is known to be true for some of the models that one can compile Firefox OS for?
I thought I would go ahead and put something about that here, since I ran into that. I wish I had a better sense of what the issue was so I could just fix it for my one device, but in case that is helpful to someone else searching for this who has not come up with the terms that led me there yet, that is apparently what is going on.
https://bugzilla.mozilla.org/show_bug.cgi?id=1121600
try replace:
<project name="platform_build" path="build" remote="gp-b2g" revision="501521623cc9a3117799a040e868bddf26b6cbde">
with:
<project name="platform_build" path="build" remote="gp-b2g" revision="3ce5007ab3562021551a35e2c06d323d1e8ee048">
and comment in config.sh (or will override your change)
repo_sync() {
rm -rf .repo/manifest* &&
to:
repo_sync() {
#rm -rf .repo/manifest* &&
finally execute the config script again
BRANCH=v2.2 ./config.sh <YOUR DEVICE>
[I am not sure whether this fits here or should be moved to apple.SE]
Today I got the idea to recompile my vim in order to get the latest updates. I have once or twice before followed the suggestion in this answer so I did it again. I cloned the repo and ran
./configure --prefix=/opt/local/ --with-features=huge
(I tried with no options, problem persists)
Invariably, compilation aborts when the compiler attempts to parse ObjC-Files (for whatever reason it has to)
/usr/include/objc/NSObject.h:22:4: error: unknown type name 'instancetype'
- (instancetype)self;
It seems the compiler does not know the current Objective-C standard.
There seems to be a problem with gcc because I found this bug ticket. However, the most recent update on this is from last year.
Can someone suggest a way to make this work?
EDIT: I know I could install it via homebrew or macports; yet I am still very curious how to fix this particular problem.
Also I tried manually changing the compiler to clang like so
CC=clang ./configure --prefix=/opt/local/ --with-features=huge
After simply setting CC=clang before running (which is what the configure help seems to advertise) and seeing it did nothing. However when specifying a compiler this way (I tried the same with gcc as well), many configure checks turn out no and it eventually aborts.
I am assuming that gcc has not been configured with Objective-C support (it supports at least C, C++ and Objective-C and the installer can opt for whatever support they want).
It's possible that the 3rd-party clang is in the same boat. However I know that the Xcode version supports all 3 languages and will pick-up the correct OSX Cocoa runtime libraries, so using that appears to have solved the issue:
$ CC="xcrun clang" ./configure --prefix=/opt/local/ --with-features=huge
However just using clang should have worked as well, if which clang returns /usr/bin/clang as you say it does, so I'm at a loss to explain exactly why that didn't work.
I have tried one day to install glibc-2.11 for sublime text.
My system is centoS 5.5 64, every time I attempted to install glibc-2.11, it ends up with configure: error: assembler too old, .cfi_personality support missing. I know it is that my system is too old. But I want to know if there is anyone have good ways to solve it.
P.S. The app of sublime test requires GLIBC 2.11.
I know it is that my system is too old.
Please note that unless done very carefully, updating glibc may easily render your system un-bootable.
The solution to configure problem is easy: update binutils first. This will give you assembler that supports .cfi directives.
Once that's done, you should be able to configure and build glibc itself.
P.S. If you don't want to update the system binutils, you can configure binutils to use a different --prefix, and set your PATH to point to that alternate location while configuring and building glibc.
So this is after having dropped $30 for Mac OS 10.7 and having downloaded XCode 4.3.2. After installing the command line tools, the installed version of gcc is still 4.2.4. I need 4.7. I've installed it and set the g++ link in /usr/bin to it. But when I try to compile any program via QtCreator, I get
unrecognized command line option -Xarch_x86_64
I found this discussed in a 3-year-old bug report here, but I really couldn't follow all the different shell commands etc. and my attempt to install liblastfm failed with the same error. The comment here,
The problem is that the GCC/G++ that is normally used to compile stuff
on Macs is actually just a wrapper.
And this wrapper has Mac-Only arguments like -Xarch_x86_64, which then
get converted into the correct args.
Seems like it might be hitting the nail on the head. Aaargh! Surely there has to be some way to get around this?
I created a custom makespec - in QtSDK/Desktop/Qt/4.8.1/gcc/mkspecs, I copied the macx-g++ folder to macx-g++47. I then removed the "include(../common/g++macx.conf)" from that and included it's contents, except for the part that generates the error (i.e. the -X... thing).
I also finished with
QMAKE_CC = gcc-mp-4.7
QMAKE_CXX = g++-mp-4.7
QMAKE_LINK = $$QMAKE_CXX
QMAKE_LINK_SHLIB = $$QMAKE_CXX
QMAKE_LINK_C = $$QMAKE_CC
QMAKE_LINK_C_SHLIB = $$QMAKE_CC
...which is similar to the spec for macx-g++42.
Now, if I add '-spec macx-g++47' to the qmake args, it works.
A lot of effort for something simple...would love to know a better way.
There are several sources for newer gcc versions for OSX. Here is a small selection:
http://hpc.sourceforge.net/ (currently gcc 4.8, previous versions might also be available)
http://gcc.gnu.org/wiki/GFortranBinaries (has gcc 4.7.0 binary installer)
I assume that you did install the command line tools from within Xcode. Apple/Xcode is not always up to date with gcc, stability is more important here than bleeding edge.