In MacOSX, gcc command line accepts multiarchitecture options:
gcc -arch i386 -arch x86_64 etc.
... and creates a universal binary by compiling and linking for both archs and running lipo for gluing them together.
However using this command line with Intel, produces a compiler warning:
command line warning #10121: overriding '-arch i386' with '-arch x86_64'
Am I doing something wrong or is this a compiler limitation?
I couldn't find anything about it in the Intel developer zone.
Related
Is there any way to run gcc with the following flags on an apple M1 chip?
gcc -m32 -o test test.c
It outputs the following error:
ld: unknown/unsupported architecture name for: -arch armv4t
clang: error: linker command failed with exit code 1 (use -v to see invocation)
You may not run 32-bit applications on macos Catalina or newer. The oldest version of macOS supported on any Apple Silicon (M1/M2) systems is Big Sur, which is the release after Catalina.
So use of -m32 on gcc or any other compiler on macOS is a not supported. Well, I suppose you could use a cross compiler to target a different operating system than the machine you are running the compiler.
Fix:
Remove -m32 and fix any issues with the code.
you can try using an IDE like Xcode or CLion as a workaround while they update GCC.
I've seen dylibs that are both 32 and 64 bit when performed the file command on. How do I go about building one in Clang?
The -m32 flag creates 32 bit dylib, -m64 makes 64 bit, but using both of them doesn't work.
Edit: For instance, here's the output of file on the type of dylib I'm trying to build
file /Library/Frameworks/SDL.framework/Versions/A/SDL
/Library/Frameworks/SDL.framework/Versions/A/SDL: Mach-O universal binary with 2 architectures
/Library/Frameworks/SDL.framework/Versions/A/SDL (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64
/Library/Frameworks/SDL.framework/Versions/A/SDL (for architecture i386): Mach-O dynamically linked shared library i386
You can either use the -arch argument multiple times for each architecture you want, e.g.
cc -arch i386 -arch x86_64 ...
or create multiple binaries, then glue them together with lipo:
lipo -create -arch i386 my32bitbinary -arch x86_64 my64bitbinary -output myfatbinary
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.
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.
I need compile a piece of C code to be called from matlab (mex compiling).
I am doing that on an intel mac and, since I am using Matlab's R2010a (7.10.0.499), I'd like to compile the C code into a version for 64-bits.
For whatever reason, just doing mex with the -arch=maci64 option did not seem to work...
As a way around, I am compiling the C code to a mexmaci64 file directly on the command line.
I used the gcc calls made by mex (with the -v option on) as a starting point.
I managed to compile the C code to an object file, but it looks like I am not compiling the C code to the correct architecture.
Does anyone know how to correct the gcc calls below so the C code gets compiled to 64-bits intel macs?
Details are listed below.
As always, any help greatly appreciated...
Keep thirsty, my friends. :p
G
DETAILS:
Here is how I did the compilation and linking:
gcc -c -I/Applications/MATLAB_R2010a.app/extern/include -DMATLAB_MEX_FILE -fno-common -no-cpp-precomp -fexceptions -D MACVERSION -DMX_COMPAT_32 -O3 -DNDEBUG "BoxQP.c"
gcc -O -bundle -Wl,-flat_namespace -undefined suppress -Wl,-exported_symbols_list,/Applications/MATLAB_R2010a.app/extern/lib/maci64/mexFunction.map -o "BoxQP.mexmaci64" BoxQP.o -L/Applications/MATLAB_R2010a.app/bin/maci64 -lmx -lmex -lmat -lstdc++
Here are the warnings I get:
ld warning: in /Applications/MATLAB_R2010a.app/bin/maci64/libmx.dylib, file is not of required architecture
ld warning: in /Applications/MATLAB_R2010a.app/bin/maci64/libmex.dylib, file is not of required architecture
ld warning: in /Applications/MATLAB_R2010a.app/bin/maci64/libmat.dylib, file is not of required architecture
Ignoring the warnings and calling the BoxQP function from matlab results in the following error message:
??? Invalid MEX-file '/Users/gvrocha/Documents/academic/projects/splice/code/matlab/covsel/BoxQP.mexmaci64':
dlopen(/Users/gvrocha/Documents/academic/projects/splice/code/matlab/covsel/BoxQP.mexmaci64, 1): no suitable image found.
Did find: /Users/gvrocha/Documents/academic/projects/splice/code/matlab/covsel/BoxQP.mexmaci64: mach-o, but wrong architecture.
PS: I tried changing the -DMX_COMPAT_32 flag to -DMX_COMPAT_64 but I do get the same warnings and same error...
PPS: I guess it may be relevant to mention that I am using Mac OS X 10.5.8 (the "tropical"/plain-vanilla Leopard, i.e., not the snow Leopard).
PPPS: The same happens with the yprime.c example provided by MATLAB