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...?
Related
I have recently started using ada for a lab in my systems programming class and I can say it is really interesting.
I tried most of it at the computers labs for testing and I decided to install the compiler and its linking tools in a MacBook.
Altough the installation is done and there seems to be no problem, when I tried to print the classic hello world program I am getting this message:
gprbuild greet.adb
using project file /Users/xyderos/opt/GNAT/2020/share/gpr/_default.gpr
Bind
[gprbind] greet.bexch
[Ada] greet.ali
Link
[link] greet.adb
ld: library not found for -lSystem
collect2: error: ld returned 1 exit status
gprbuild: link of greet.adb failed
gprbuild: failed command was: /users/name/opt/gnat/2020/bin/gcc greet.o b__greet.o - L/Users/name/ada/ -L/Users/name/ada// -L/users/name/opt/gnat/2020/lib/gcc/x86_64-apple-darwin17.7.0/8.4.1/adalib/ /users/name/opt/gnat/2020/lib/gcc/x86_64-apple-darwin17.7.0/8.4.1/adalib/libgnat.a -Wl,-rpath,#executable_path/ -Wl,-rpath,#executable_path/..//opt/gnat/2020/lib/gcc/x86_64-apple-darwin17.7.0/8.4.1/adalib -o greet
I am getting really confused about the lSystem library.
It seems that the library doesn't exist on Mac(maybe I need to install Xcode?).
Does anyone have a clue about that issue or is there a probably better way to install it via brew?
Thanks a lot in advance!
On my MacOS 10.14, the following worked for me, without having to download the massive blob that is Xcode, which I had neither the bandwidth nor the diskspace for. I don't know if this still works on MacOS 10.15 (not planning to upgrade).
Most of this info was from a blog post by Simon Wright: https://forward-in-code.blogspot.com/2019/06/macos-software-development-kit-changes.html
You only need the Xcode command line tools only (not Xcode): xcode-select --install
Now unpack the included headers: sudo installer -pkg /Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg -target /
And tell GNAT where to find them: mv ce2109-specs /usr/local/opt/GNAT/2019/lib/gcc/x86_64-apple-darwin17.7.0/8.3.1/specs
The ce2109-specs file is from the blog post above. This did the job for me and GNAT can now link working binaries on MacOS 10.14.
If you're on 10.15 and it doesn't work (because there's no more Xcode command line tools or they're missing the headers package), you will unfortunately have to install Xcode as per the GNAT Readme.
[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 spent an evening until some ridiculous time in the morning trying to figure out how to get Haskell's GHC to work correctly and to have Cabal install the gloss library.
After reading through every bit of documentation/error reports imaginable, even with old installs of ghc, gcc binary (instead of a symlink to clang), and brewing llvm no matter what happened one fix resolved one issue, only to then present another.
So I have a simple solution that worked for me for Yosemite and I will post it below (I wish someone else had posted it here)
Ok here is the easy solution to the headache:
Go here http://ghcformacosx.github.io/ and download the app and put it in the app directory and run it.
Add the stuff to the .bash_profile (you will see what I mean when you run it)
Run brew install llvm34 (note there was an issue with using a newer version)
Then symlink to llvm so that ghc can find it (I tried editing the ghc settings file but it didn't help. Maybe after all the stuffing around, it was the wrong version of ghc that I was editing)
Brew gave me symlinks at /user/local/bin to llvm BUT NOTE they were not called plain old llc & opt as ghc was looking for.. they were called llc-3.4 & opt-3.4, hence why it couldn't find them. Again their location can be specified in the ghc settings file, but as I had some issues with that I just created some more symlinks.
I went to /usr/bin and ran:
sudo ln -s /usr/local/bin/opt-3.4 opt
sudo ln -s /usr/local/bin/llc-3.4 llc
Which created the generic opt, generic llc that symlinked to the brew installion of the associated v3.4.2 llvm files.
Hope that saves someone an evening.
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.
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.