We have a large Carbon based (PowerPlant) application that we are looking finally to port over to Cocoa. We will be doing this incrementally and a first step is to try to get a Cocoa view into a Carbon window.
The problem seems to be that when I use any of the functions from HICocoaView.h the application will not compile unless I switch the compiler from GCC 4.2 to GCC 4.0.
Using any compiler other than GCC 4.0 I get an error in XCode that the functions are unavailable e.g. "HICocoaViewCreate is unavailable".
I can't figure out why this won't work, will we have to switch to the older compiler or is there some setting we can change to get it to compile?
Any help or pointers to useful documentation on porting Carbon to Cocoa greatly appreciated. I've read through the old Carbon Cocoa Integration guide but it doesn't mention this.
Edit: As requested here's the output from the build for the gcc command line:-
/Developer/usr/bin/gcc-4.2 -x objective-c++ -arch i386
-fmessage-length=0 -pipe -Wno-trigraphs -fpascal-strings -fasm-blocks -O0 -Wmissing-prototypes -Wreturn-type -Wunused-variable -Wunused-value -D__IMPRO_DEBUG_BUILD__ -isysroot /Developer/SDKs/MacOSX10.5.sdk -mfix-and-continue
-mmacosx-version-min=10.5 -gdwarf-2 "-I/Users/matt/Code/MattsFeatureBranch/Modules/User
Notes/Mac/../../../(Intermediates)/Debug/User Notes.build/Debug/Module
Bundle.build/User Notes.hmap" -Wparentheses -Wno-conversion
-Wno-sign-compare -Wno-multichar -Wno-deprecated-declarations "-F/Users/matt/Code/MattsFeatureBranch/Modules/User
Notes/Mac/../../../Build Products/Mac/Debug/Plugins" "-F../../../Build
Products/Mac/Debug" "-F../../../Third Party/Mac/NVidia"
"-I/Users/matt/Code/MattsFeatureBranch/Modules/User
Notes/Mac/../../../Build Products/Mac/Debug/Plugins/include"
-I../X-Platform -I../../../Common/Mac -I../../../Common/X-Platform -I../../../DLLs/ArcadiaCore/Mac -I../../../DLLs/ArcadiaCore/X-Platform "-I../../../Third Party/Mac/Powerplant"
-I/Developer/SDKs/MacOSX10.5.sdk/Developer/Headers/FlatCarbon "-I../../../Third Party/X-Platform/boost_1_38_0"
-I../../../DLLs/ArcadiaImaging/Mac -I../../../DLLs/ArcadiaImaging/X-Platform -I../../../DLLs/ArcadiaDatabase/Mac -I../../../DLLs/ArcadiaDatabase/X-Platform -I../../../DLLs/ArcadiaUI/Mac -I../../../DLLs/ArcadiaUI/X-Platform "-I../../../Third Party/Mac/Powerplant Extras"
-I../../../DLLs/ArcadiaDevices/Mac -I../../../DLLs/ArcadiaDevices/X-Platform -I../../../DLLs/Arcadia3D/Mac -I../../../DLLs/Arcadia3D/X-Platform "-I/Users/matt/Code/MattsFeatureBranch/Modules/User
Notes/Mac/../../../(Intermediates)/Debug/User Notes.build/Debug/Module
Bundle.build/DerivedSources/i386"
"-I/Users/matt/Code/MattsFeatureBranch/Modules/User
Notes/Mac/../../../(Intermediates)/Debug/User Notes.build/Debug/Module
Bundle.build/DerivedSources" -fpermissive -fasm-blocks -include
"/Users/matt/Code/MattsFeatureBranch/Modules/User
Notes/Mac/../../../(Intermediates)/Debug/SharedPrecompiledHeaders/XPrefix-acshmfbgvfwrdqbyayvgnckkypgr/XPrefix.h"
-c "/Users/matt/Code/MattsFeatureBranch/Modules/User Notes/Mac/MUserNotesView.cpp" -o
"/Users/matt/Code/MattsFeatureBranch/Modules/User
Notes/Mac/../../../(Intermediates)/Debug/User Notes.build/Debug/Module
Bundle.build/Objects-normal/i386/MUserNotesView.o"
From HICocoaView.h in both the 10.5 and the 10.6 SDK:
#if !__LP64__
extern OSStatus
HICocoaViewCreate(
NSView * inNSView, /* can be NULL */
OptionBits inOptions,
HIViewRef * outHIView) AVAILABLE_MAC_OS_X_VERSION_10_5_AND_LATER;
…
#endif /* !__LP64__ */
This means that HICocoaViewCreate() is not available on 64-bit (LP64) targets, i.e., if you need to use this function you have to target i386 (or PowerPC).
GCC 4.0 targets i386 by default even when run on 64-bit capable machines. On the other hand, GCC 4.2 targets x86_64 by default on 64-bit machines:
$ gcc-4.0 a.c; lipo -info a.out
Non-fat file: a.out is architecture: i386
$ gcc-4.2 a.c; lipo -info a.out
Non-fat file: a.out is architecture: x86_64
If you want to use both HICocoaViewCreate() and GCC 4.2, tell it to create (and use) 32-bit objects/binaries by passing -arch i386. For instance,
$ gcc-4.2 a.c -arch i386; lipo -info a.out
Non-fat file: a.out is architecture: i386
Even though part of Carbon is available for 64-bit targets, you’ll notice in the 64-bit Guide for Carbon Developers that much of HIToolbox simply isn’t available.
As for migrating from Carbon to Cocoa, it’s a whole new Objective-C API for the most part. I’m not aware of any simple migration guide, and Peter Hosey’s answer to a similar question on Stack Overflow is worth reading.
Related
Running the build script from ELLCC results in this error
gcc -DHAVE_CONFIG_H -I. -I../../../src/binutils/binutils -I. -I../../../src/binutils/binutils -I../bfd -I../../../src/binutils/binutils/../bfd -I../../../src/binutils/binutils/../include -I./../intl -DLOCALEDIR="\"/Library/Caches/Homebrew/ellcc--svn-HEAD/lib/share/locale\"" -Dbin_dummy_emulation=bin_vanilla_emulation -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -Wno-unused-value -Wno-shadow -MT nm.o -MD -MP -MF .deps/nm.Tpo -c -o nm.o ../../../src/binutils/binutils/nm.c
../../../src/binutils/binutils/nm.c:1690:28: error: 'sbrk' is deprecated
[-Werror,-Wdeprecated-declarations]
char *lim = (char *) sbrk (0);
^
/usr/include/unistd.h:582:7: note: 'sbrk' declared here
void *sbrk(int);
^
The following compilers have been used with the same result:
gcc 4.8
llvm-gcc 2.8
llvm 3.3
I had the same issue compiling binutils-2.24 on Mac OSX Mavericks 13.2.0 with clang. Thanks to Richard Pennington's suggestion, I was able to get binutils to compile by specifying a few other -Wno-error arguments to gcc by setting CFLAGS before running configure. Namely, these are the commands I ran to build and install binutils:
CFLAGS="-Wno-error=deprecated-declarations -Wno-error=unused-variable -Wno-error=unused-function" ./configure --prefix=/usr/local/toolchain-arm-linux-elf --target=arm-linux-elf
make
make install
EDIT: I just noticed that the binutils configure script accepts an --disable-werror argument, which disables gcc turning warnings into errors, and removes the need for the settings CFLAGS. With this argument, building could be done as follows:
./configure --prefix=/usr/local/toolchain-arm-linux-elf --target=arm-linux-elf --disable-werror
make
make install
This error is occurring because sbrk() is deprecated on OSX, -Werror is enabled for the binutils build, and the compiler (in this case "gcc" is an alias for clang) rightly complains about the use of sbrk(). I'll be looking into eliminating this error this weekend when I won't have to be at my day job. ;-)
I looked into it a bit more. This happened because the latest version of OS X (Mavericks) uses clang as its compiler and /usr/include/unistd.h has a deprecated declaration of sbrk().
The solution was to add a -Wno-error=deprecated-declarations option to the CFLAGS for binutils. I also had to make a few other changes to complete the Max OS build. You can find the latest stuff in the ELLCC subversion tree.
I'm trying to get llvm-gcc 4.2.2.9 to compile on this x86_64 system which runs the 3.0.0-21-generic kernel. llvm 2.9 itself builds fine. I suspected the downloadable version of llvm-gcc was causing some other problems, so I decided to build llvm-gcc myself.
Like suggested in the README.LLVM I configured with
../llvm-gcc-4.2-2.9.source/configure \
--prefix=/opt/llvm-gcc4.2-2.9/../llvm-gcc4.2-2.9-install \
--disable-multilib \
--program-prefix=llvm- \
--enable-llvm=/opt/llvm-2.9 \
--host=x86_64-generic-linux-gnu
--enable-languages=c,c++
I'm running this from the /opt/llvm-gcc4.2-2.9 directory, while the sources are sitting in /opt/llvm-gcc-4.2-2.9.source and my llvm 2.9 lives in /opt/llvm-2.9. Note that I'm setting the --host instead of the --target as this implicitly sets the --target to the same architecture.
make does build a lot of stuff (producing a sizeable amount of warnings) when finally stopping at this error:
make[3]: Entering directory `/opt/llvm-gcc4.2-2.9/gcc'
/opt/llvm-gcc4.2-2.9/./gcc/xgcc -B/opt/llvm-gcc4.2-2.9/./gcc/ -B/opt/llvm-gcc4.2-2.9/../llvm-gcc4.2-2.9-install/x86_64-generic-linux-gnu/bin/ -B/opt/llvm-gcc4.2-2.9/../llvm-gcc4.2-2.9-install/x86_64-generic-linux-gnu/lib/ -isystem /opt/llvm-gcc4.2-2.9/../llvm-gcc4.2-2.9-install/x86_64-generic-linux-gnu/include -isystem /opt/llvm-gcc4.2-2.9/../llvm-gcc4.2-2.9-install/x86_64-generic-linux-gnu/sys-include -O2 -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -I. -I. -I../../llvm-gcc-4.2-2.9.source/gcc -I../../llvm-gcc-4.2-2.9.source/gcc/. -I../../llvm-gcc-4.2-2.9.source/gcc/../include -I../../llvm-gcc-4.2-2.9.source/gcc/../libcpp/include -I../../llvm-gcc-4.2-2.9.source/gcc/../libdecnumber -I../libdecnumber -I/opt/llvm-2.9/include -g0 -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -fno-toplevel-reorder -fno-omit-frame-pointer -fno-asynchronous-unwind-tables \
-c ../../llvm-gcc-4.2-2.9.source/gcc/crtstuff.c -DCRT_BEGIN \
-o crtbegin.o
In file included from /usr/include/stdio.h:28,
from ../../llvm-gcc-4.2-2.9.source/gcc/tsystem.h:90,
from ../../llvm-gcc-4.2-2.9.source/gcc/crtstuff.c:68:
/usr/include/features.h:323:26: error: bits/predefs.h: No such file or directory
/usr/include/features.h:356:25: error: sys/cdefs.h: No such file or directory
/usr/include/features.h:388:23: error: gnu/stubs.h: No such file or directory
I find it a bit odd that the include path goes from my system's stdio.h back to llvm-gcc headers and then tries again to include system headers. But maybe that's normal?
After that error hundreds of lines with more errors follow from the same compilation unit.
Could it be that my system's gcc 4.6.1 or my system's headers maybe grew incompatible with the dated llvm-gcc 4.2 headers? Then again, I know that on a different system (running the 2.6 kernel) gcc 4.5.2 plays well with llvm 2.7's gcc 4.2.
I'm at a loss here, because I do need a recent llvm 2.*, and the other two acceptable llvm versions (2.7, 2.8) didn't show any result more helpful.
It seems that /usr/include on your system provides 32-bit headers, thus the compilation fails since you do not have all multilib headers installed. You might need to patch llvm-gcc the same way as your distribution patches gcc in order to find the headers locations.
Alternatively, you might try to install 32-bit headers and try multilib build of llvm-gcc.
But the best way will be switch to LLVM 3.1 and clang :)
I've recently installed Xcode 4.2 on my macbookpro 10.7.2 . I have my drived partitioned by BootCamp. When I installed XCode 4.2, I ran XCode and I try to see if it can simply build stuff so I picked a Command Line Tool. When the wizard is done generating the files, I simply ran it and it already gave me an error. I tried other templates and it generated the same error. Whats the solution for this problem?
Anyway, this is the error:
Clang LLVM 1.0 Error
Command /Developer/usr/bin/clang failed with exit code 11
ProcessPCH /Users/revin122/Library/Developer/Xcode/DerivedData/SecondApp-dderlmctlgoalofwkqvuhanbimji/Build/PrecompiledHeaders/SecondApp-Prefix-grjbjgpsgeilsbghzjmhjjxmgsqx/SecondApp-Prefix.pch.pth SecondApp/SecondApp-Prefix.pch normal x86_64 objective-c com.apple.compilers.llvm.clang.1_0.compiler
cd /Users/revin122/Downloads/Ex_Files_ObjC_EssT/exercise_files/ch03/SecondApp
setenv LANG en_US.US-ASCII
/Developer/usr/bin/clang -x objective-c-header -arch x86_64 -fmessage-length=0 -fdiagnostics-print-source-range-info -fdiagnostics-show-category=id -fdiagnostics-parseable-fixits -std=gnu99 -Wno-trigraphs -fpascal-strings -O0 -Wreturn-type -Wparentheses -Wswitch -Wno-unused-parameter -Wunused-variable -Wunused-value -Wshorten-64-to-32 -DDEBUG -isysroot /Developer/SDKs/MacOSX10.7.sdk -fasm-blocks -mmacosx-version-min=10.6 -gdwarf-2 -Wno-sign-conversion "-DIBOutlet=__attribute__((iboutlet))" "-DIBOutletCollection(ClassName)=__attribute__((iboutletcollection(ClassName)))" "-DIBAction=void)__attribute__((ibaction)" -iquote /Users/revin122/Library/Developer/Xcode/DerivedData/SecondApp-dderlmctlgoalofwkqvuhanbimji/Build/Intermediates/SecondApp.build/Debug/SecondApp.build/SecondApp-generated-files.hmap -I/Users/revin122/Library/Developer/Xcode/DerivedData/SecondApp-dderlmctlgoalofwkqvuhanbimji/Build/Intermediates/SecondApp.build/Debug/SecondApp.build/SecondApp-own-target-headers.hmap -I/Users/revin122/Library/Developer/Xcode/DerivedData/SecondApp-dderlmctlgoalofwkqvuhanbimji/Build/Intermediates/SecondApp.build/Debug/SecondApp.build/SecondApp-all-target-headers.hmap -iquote /Users/revin122/Library/Developer/Xcode/DerivedData/SecondApp-dderlmctlgoalofwkqvuhanbimji/Build/Intermediates/SecondApp.build/Debug/SecondApp.build/SecondApp-project-headers.hmap -I/Users/revin122/Library/Developer/Xcode/DerivedData/SecondApp-dderlmctlgoalofwkqvuhanbimji/Build/Products/Debug/include -I/Users/revin122/Library/Developer/Xcode/DerivedData/SecondApp-dderlmctlgoalofwkqvuhanbimji/Build/Intermediates/SecondApp.build/Debug/SecondApp.build/DerivedSources/x86_64 -I/Users/revin122/Library/Developer/Xcode/DerivedData/SecondApp-dderlmctlgoalofwkqvuhanbimji/Build/Intermediates/SecondApp.build/Debug/SecondApp.build/DerivedSources -F/Users/revin122/Library/Developer/Xcode/DerivedData/SecondApp-dderlmctlgoalofwkqvuhanbimji/Build/Products/Debug -c /Users/revin122/Downloads/Ex_Files_ObjC_EssT/exercise_files/ch03/SecondApp/SecondApp/SecondApp-Prefix.pch -o /Users/revin122/Library/Developer/Xcode/DerivedData/SecondApp-dderlmctlgoalofwkqvuhanbimji/Build/PrecompiledHeaders/SecondApp-Prefix-grjbjgpsgeilsbghzjmhjjxmgsqx/SecondApp-Prefix.pch.pth -MMD -MT dependencies -MF /Users/revin122/Library/Developer/Xcode/DerivedData/SecondApp-dderlmctlgoalofwkqvuhanbimji/Build/PrecompiledHeaders/SecondApp-Prefix-grjbjgpsgeilsbghzjmhjjxmgsqx/SecondApp-Prefix.pch.d
Command /Developer/usr/bin/clang failed with exit code 11
To try and narrow down the problem here, one thing to try would be to change the compiler from "Apple LLVM Complier 3.0" to "LLVM GCC 4.2" and see if you get different results. That might start to narrow down what is going on.
The other thing worth trying is just to re-install Xcode 4.2. A few people—myself included—found the initial install was bad but reinstalling over the top fixed the problem.
I need to suppress "-arch x86_64 -arch i386" flags Waf is passing to GCC.
I am building an SDL/Opengl application. If I link against 32 bit SDL runtime I get error
Undefined symbols for architecture i386:
"_SDL_Quit", referenced from:
__del_video in SDL_functions.c.2.o
__init_video in SDL_functions.c.2.o
If I link against 64 bit SDL runtime, I get error "Undefined symbols for architecture x86_64"
The compiler is apparently using flags
-arch x86_64 -arch i386
I understand that this causes GCC on OSX to try to compile for both architectures. I want to either compile for 64 bit, or compile for 32 bit. How do I suppress the flags for one architecture?
I found out in my case that the double arch flags were originating here, specifically from distutils.sysconfig.get_config_var('LDFLAGS'). This returns the LDFLAGS that Python thinks you should link Python modules with. In my case, file $(which python) is a "Mach-O universal binary with 2 architectures", so Python thinks you should link with -arch x86_64 -arch i386 -Wl,F.
My problem was that I was building a Python native module that needed to link against Python and another library which was not built with both arches. When building my module with both arches, linking failed with "symbols not found", because both arches were not available in the third-party library.
Since waf unfortunately doesn't allow you to override its computed flags with your own flags, as Automake does, I could only fix this by messing directly with my ctx() object in my wscript:
for var in ['CFLAGS_PYEMBED', 'CFLAGS_PYEXT', 'CXXFLAGS_PYEMBED',
'CXXFLAGS_PYEXT', 'LINKFLAGS_PYEMBED', 'LINKFLAGS_PYEXT']:
newvar = []
for ix, arg in enumerate(ctx.env[var]):
if '-arch' not in (arg, ctx.env[var][ix - 1]):
newvar.append(arg)
ctx.env[var] = newvar
(This removes all -arch flags and their arguments from the relevant variables. Since I was also passing my own -arch flag in my CFLAGS, it now does not get overridden.)
I don't know of a way to issue a command/flag to suppress other flags. However, to compile for only 64 or 32 bits, you can use -m64 or -m32, respectively. Since you're compiling for both architectures, -m32 might be your only option because -m64 won't work for i386.
As is asked and answered in this post, I needed to give -arch i386 option for SWIG/C# integration.
Do I need to give the option for both compilation/link?
g++ -c -arch i386 example.cxx example_wrap.cxx
g++ -arch i386 -bundle -undefined suppress -flat_namespace example.o example_wrap.o -o libexample.dylib
Have you tried it? A simple test with a C program on OS X 10.6 with a 64-bit capable machine suggests that, in general, you do need to specify -arch for both.
$ gcc -arch i386 -o x.o x.c
$ gcc x.o -o x.dylib
ld: warning: in x.o, file was built for i386 which is not the architecture being linked (x86_64)
Intuitively, the linker does need to know which set of architecture-specific libraries to link with.