I seem to have a problem with Yosemite compiling.
I Have downloaded
dtrace-118.1
AvailabilityVersions-9
xnu-2782.1.97
It seems like the command line tools are not installed but a previous kernel version works, I replaced the makedefs folder from the previous kernel and well it starts compiling but of course fails.
The error I have is here:
[removed]
I had the same issue. It's because the new kernel uses the macosx.internal SDK to compile by default which obviously isn't available because it's Apples internal SDK. If you use the standard macosx SDK it'll compile fine. I used:
make TARGET_CONFIGS="RELEASE X86_64 NONE" SDKROOT=macosx
And I'm currently running the kernel without any issues on my late 2009 MacBook. If you have a Haswell CPU then change the arch type to "X86_64H".
Also while I'm on the topic I noticed there's a couple of new platforms listed under SUPPORTED_PLATFORMS in makedefs/MakeInc.def. iPhoneOSNano and iPhoneNanoSimulator. I'm guessing they're for the Apple Watch. None of the actual code is available but it's mentioned in some makefiles.
Fixed, problem in the xnu-2782.1.97/makedefs -> MakeInc.cmd Line 37 SDKROOT ?= macosx.internal Replace SDKROOT ?= / –
Related
Recently (since Catalina was released and xcode updated, but I am still running Mojave) I have found the gcc, installed via macports, has broken. I get errors saying that the system includes cannot be found:
ld: library not found for -lSystem
I have tried the solution here: Can't compile C program on a Mac after upgrade to Mojave - but when I install macOS_SDK_headers_for_macOS_10.14.pkg it doesn't actually create anything in /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs ; all I see in there is the 10.15 (Catalina) sdk!
If I instead just sym link MacOSX10.14.sdk to MacOSX10.15.sdk (possibly not a great idea), I get a different set of errors:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/wchar.h:90,
from /opt/local/include/gcc8/c++/cwchar:44,
from /opt/local/include/gcc8/c++/bits/postypes.h:40,
from /opt/local/include/gcc8/c++/iosfwd:40,
from /opt/local/include/gcc8/c++/ios:38,
from /opt/local/include/gcc8/c++/ostream:38,
from /opt/local/include/gcc8/c++/iostream:39,
from /Users/pae9/soft/src/cmake/LIGO_support/restrictHealMap.cpp:4:
/opt/local/lib/gcc8/gcc/x86_64-apple-darwin18/8.3.0/include-fixed/stdio.h:222:7: error: conflicting declaration of 'char* ctermid(char*)' with 'C' linkage
char *ctermid(char *);
In other words, now it appears that the macports headers are conflicting with the xcode ones.
I never had a problem before; I think this issue dates to the last xcode update (currently on Version 11.2 (11B52))
Any thoughts or suggestions very welcome - I'd really like to be able to go back to compiling code using gcc!
FYI I'm using gcc7 (from macports), for consistency with the linux servers which are my actual live systems, but I have tried gcc 8 and 9 and get the same results.
cd /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/
sudo ln -s MacOSX10.15.sdk MacOSX10.14.sdk
OK, it seems that if I do the ln -s as above, and also move #include to be the first include in all my files, the problem goes away.
This looks to me like a serious problem in the Apple SDK headers, because surely conflicting definitions like this shouldn't occur...?
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.
Is here anyone who successfully build Google Breakpad on MacOS using standard Qt tool chain without xcode?
I'm trying to get work this library for two days now and still without success. I already successfully compiled it and ran it on Windows and Linux. (from original Google-git repository).
But MacOS version of library has missing makefile for libbreakpad_client.a and generated libbreakpad.a does not contain the exception handler.
http://screencast.com/t/V0mNiM3kZ
I found few topic about this issue on here on a stackoverflow but advice with updated makefiles didn't work for me (or I didn't copy makefiles correctly).
I also tried to download updated version directly from Mozilla repository (version 10 and 11beta). But when I tried to compile Mozilla version, there was another errors with undefined symbols (on Mac and also on Linux).
I also found AlekSi - breakpad-qt but this version also works correctly only under Win and Linux. Under Mac there is some errors about "Unknown architecture -- are you on a PDP-11?"
I will be gratitude to anyone who can point me how to compile it and get it work under Mac or who can send me a packed version of breakpad which can be compiled under MacOS using standard make and used in Qt application.
Thank you
Ludek
AlekSi's breakpad-qt is three years old, and the breakpad source in it doesn't support 64 bits on OSX.
Failing to detect your processor type is what makes it complain about "Unknown architecture -- are you on a PDP-11?".
You definitely need a more recent breakpad version, either from their svn, or from my breakpad-qt fork at: https://github.com/webitup/qt-breakpad
Now, if you intend on supporting 10.6 (MACOSX_DEPLOYMENT_TARGET=10.6) as well, you need to patch breakpad source using this https://github.com/webitup/qt-breakpad/commit/71a9fdedd827e5939ba66bfcc0cd6c1c9fbbc87b (-> I don't think 10.6 has PPC support)
Then:
You apparently managed to compile directly from source, so, good for that way.
Now, if you want to build a framework from breakpad instead, and link to that from your qt app/lib, then Dave Mateer suggestion is the way to go (and he deserves the credit). The following worked for me:
cd $BREAKPAD_SOURCE_TREE
xcodebuild -sdk macosx10.7 -project src/client/mac/Breakpad.xcodeproj -configuration Release -target Breakpad ARCHS=x86_64 ONLY_ACTIVE_ARCH=YES MACOSX_DEPLOYMENT_TARGET=10.6 GCC_VERSION=com.apple.compilers.llvmgcc42
Note that I'm only building target Breakpad instead of All (it seems you only need that - and a test is failing for me using All, though it does produce a usable framework either way).
And note that you don't require XCode per-se - just the command line builds tools.
In order to use that framework in your QT project:
mac {
QMAKE_LFLAGS += -F$$BREAKPAD_PATH/client/mac/build/Release/
LIBS += -framework Breakpad
}
And you should be set.
Finally: I also pushed a number of changes in my breakpad-qt fork source itself to have it at least compile (on OSX!) against the updated breakpad version, but I have no idea yet if it does work properly.
I'm just starting with that fork - if you want to share experience and/or commit some stuff in there, just ask.
I have been trying to build ECL under OS X 10.7 and I have been
running into trouble. When I try building it I end up getting a
segfault on the ecl_min stage.
I configure with the following line:
./configure --build=x86_64 --target=x86_64 --prefix=`pwd`/install_ecl
CC=/Developer/usr/bin/gcc-4.2
And the compile fails with:
if [ -f CROSS-COMPILER ]; then \
./CROSS-COMPILER compile; \
else \
ECLDIR=`pwd`/ ./ecl_min compile; \
fi
/bin/sh: line 1: 17433 Segmentation fault: 11 ECLDIR=`pwd`/ ./ecl_min compile
I have tried building gmp and boehm-gc externally and not using the
included ones, but unfortunately it ended up with the same results. I
have also tried the default llvm-gcc without much luck either.
Has anyone been able to compile ECL under Lion, and if so, what configure options / patches did you need to apply.
Update:
I was able to compile thanks to the accepted answer below. Here is the scripts that I used (Note: This is from a fresh git clone of ECL):
#!/bin/sh
ECL_INSTALLDIR="`pwd`/install_ecl"
mkdir -p $ECL_INSTALLDIR
./configure\
--prefix=$ECL_INSTALLDIR\
--enable-boehm\
--enable-unicode=no\
CC=/Developer/usr/bin/gcc\
CXX=/Developer/usr/bin/g++\
CFLAGS="$CFLAGS"
LDFLAGS="$LDFLAGS"
make && make install
This problem has been fixed in git/CVS. As explained above, the cause for the miscompilation was the version of our garbage collector: we shipped the last one available: 7.1, but this does not work with OS X Lion. ECL now ships with two versions (7.1 and 7.2-cvs), using the newest one in OS X Lion. In other words, ECL from git/CVS (http://ecls.sourceforge.net/download.html) should compile and run out of the box.
This page describes the two causes of the problem (an issue with the compiler, and an issue with garbage collector compatibility), and offers a temporary solution until the issue itself is fixed. The instructions come down to:
Download a new build of the Boehm-Weiser garbage collector library, apply a patch (you can get a link to download both the library and the patch from that page as well), and install it somewhere
Configure ECL with these extra options:
--enable-boehm=system
CPPFLAGS=-I/location/for/library/include
LDFLAGS=-L/location/for/library/lib
Where /location/for/library is the prefix you used to install the garbage collector.
And then it should build properly.
I also found this MacPorts ticket which seems to be tracking this issue; check there for future updates to see if it will be fixed.
I have a unix command line app (with big nasty makefile) that I'm trying to run on a mac. I am compiling it on a 10.6 system, with all of the appropriate libraries of course. The deployment environment is a 10.5 system, with no extra libraries.
I compiled without -dynamic, and it appears to have static libraries, correctly. When I run it on the 10.6 system, it works. However, when I run it on the 10.5 system, I get:
dyld: unknown required load command 0x80000022
I got this same error when I compiled things for the 10.6 system using the 10.5 xcode, so it looks like a version mis-match type problem. However, I used gcc-4.0, and
$CFLAGS = -isysroot /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5
so it SHOULD be set up for 10.5... any ideas?
thanks
Editing an ancient question:
I have the exact same problem on a different computer. This time I am at 10.5.8, fully update, the same executable works on 10.6 still.
Has anyone had any luck with this in the months since I asked this?
The reason for the dyld 0×80000022 error can be that, you are linking on OS X 10.6, and OS X 10.6 will use a load command (LC_DYLD_INFO_ONLY = 0×80000022) that OS X 10.5 does not understand.
To fix this, make sure you are using a deployment target by setting the environment variable just before your link command:
export MACOSX_DEPLOYMENT_TARGET=10.5
(or setenv MACOSX_DEPLOYMENT_TARGET=10.5)
You can always check if your executable uses the right load command like this:
otool -l executable
It will either show LC_DYLD_INFO_ONLY (without deployment target) commands or LC_DYLD_INFO (with deployment target).
I have been searching for the same issue, as I develop on 10.6 but must have a version that works on 10.5. In addition to the compiler flags above, you should add:
-no_compact_linkedit
It is described here:
http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPages/man1/ld.1.html
where it says:
Normally when targeting Mac OS X 10.6, the linker will generate compact information in the __LINKEDIT segment. This option causes the linker to instead produce traditional relocation information.
I got there from a discussion on the xcode-users mailing list about "unknown required load command 0x80000022".
i was able to solve this by passing -mmacosx-version-min=10.5 to the linker, e.g. --extra-ldflags="-mmacosx-version-min=10.5" passed to configure for ffmpeg which i was building shared. more info: http://lists.apple.com/archives/xcode-users/2009/Oct/msg00530.html
Depending on how many libraries you use, it may be difficult to get all of them linked statically. What does "otool -L your_binary' tell you?
In order to get a self-contained package for an application of my own, I made a custom MacPorts install in a non-standard directory, so that I could dynlink with the libraries from that directory and only be constrained in asking people to install the whole thing in the same place on their computers. Not great, not the Mac spirit at all, but it's an Unix app and you need to be familiar with Unix to use it anyway.
Good luck
Pascal
It turns out that there is a dynamic library load function (0x22) that got added at 10.5.6. The system I was running on was 10.5.5. I upgraded to 10.5.8, and everything runs!
Ok, SECOND solution, and NOT very satisfying, is to find a 10.5.8 computer, install the developer packages and re-compile... same for powerPC... sad but it will work...