Xcode contains 2 architectures.The Xcode App is too big.
$ file /Applications/Xcode.app/Contents/MacOS/Xcode /Applications/Xcode.app/Contents/MacOS/Xcode: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64:Mach-O 64-bit executable arm64] /Applications/Xcode.app/Contents/MacOS/Xcode (for architecture x86_64): Mach-O 64-bit executable x86_64 /Applications/Xcode.app/Contents/MacOS/Xcode (for architecture arm64): Mach-O 64-bit executable arm64
arm64 seems useless, how do I delete it
Related
After I started using MacOS Ventura with Xcode 14, compiling a Fortran code in a conda environment failed. The error seems to be due to ld:
ld: unsupported tapi file type '!tapi-tbd' in YAML file
'/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/usr/lib/libSystem.tbd'
for architecture x86_64
The ld in Anaconda3/bin/ supports only Apple TAPI version 10.0.0
#(#)PROGRAM:ld PROJECT:ld64-530 BUILD 07:42:29 Sep 7 2022 configured
to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 x86_64
x86_64h armv6m armv7k armv7m armv7em (tvOS)
LTO support using: LLVM version 14.0.6 (static support for 26, runtime is 29)
TAPI support using: Apple TAPI version 10.0.0 (tapi-1000.10.8)
Outside Anaconda, compiling works and the ld in /usr/bin/ supports Apple TAPI version 14.0.0
#(#)PROGRAM:ld PROJECT:ld64-819.6 BUILD 21:47:27 Sep 13 2022
configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32
i386 x86_64 x86_64h armv6m armv7k armv7m armv7em LTO support using:
LLVM version 14.0.0, (clang-1400.0.29.102) (static support for 29,
runtime is 29) TAPI support using: Apple TAPI version 14.0.0
(tapi-1400.0.11)
To fix the problem, first, I tried both Xcode 14.01 and 14.1 (13.4 was incompatible with Ventura), but they didn't work.
Second, I tried using old SDK following here, but this also didn't work.
Since I want to stay in a conda environment managing python tools combined with Fortran,
any way to resolve the issue is very much appreciated!
I am making a project in Mac OSX and use the boost compiled libraries (serialisation amongst others). I installed all my dependencies as x86_64 libraries, but now want to make explicitly 32 bit ones (i386) and recompile my project for 32bit users.
I have recompiled by libraries with g++ -m32 where appropriate and then re made 32 bit boost libraries using
./bootstrap.sh link=static
./b2 cflags=-m32 cxxflags=-m32 address-model=32 threading=multi architecture=x86 instruction-set=i686
I then recompile my project by explicitly linking to the 32 bit libraries. So something like
g++ file.cpp /usr/local/lib/boost_i386/libboost_serialization.a -m32 -o executable
where the library is explicitly the 32 bit version verified by using otool as follows with (partial) output (all list cputype as i386)
otool -hv -arch all libboost_serialization.a
Archive : libboost_serialization.a
libboost_serialization.a(basic_archive.o):
Mach header
magic cputype cpusubtype caps filetype ncmds sizeofcmds flags
MH_MAGIC I386 ALL 0x00 OBJECT 3 1180 SUBSECTIONS_VIA_SYMBOLS
However, when I compile my project (despite most dependencies working fine), it trips up and that symbols are missing for this architecture
Explicitly:
Undefined symbols for architecture i386:
"boost::archive::detail::shared_ptr_helper::shared_ptr_helper()", referenced from:
boost::archive::binary_iarchive::binary_iarchive(std::basic_istream<char, std::char_traits<char> >&, unsigned int)in ccCH1ama.o
"boost::archive::detail::shared_ptr_helper::~shared_ptr_helper()", referenced from:
boost::archive::binary_iarchive::~binary_iarchive()in ccCH1ama.o
boost::archive::binary_iarchive::~binary_iarchive()in ccCH1ama.o
ld: symbol(s) not found for architecture i386
collect2: ld returned 1 exit status
I have explicitly built the 32bit libraries, checked they are in fact 32 bit, and explicitly linked to them, I don't know what else to do. Any ideas?
Turns out the header files were boost v1.55 but the i386 libraries used the most current version v1.57. This caused the error. Building the libraries with the older v1.55 to match the headers fixed the problem.
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'm trying to build omnet++ on Mac OS X Lion.
configure works fine, however I got this error when creating tk shared library.
Creating shared library: /Applications/omnetpp-4.3/lib/cc_-arch_i386/libopptkenv.dylib
ld: warning: ld: warning: ignoring file /Applications/omnetpp-4.3/out/cc_-arch_i386-
release/src/tkenv/tkImgPNG.o, file was built for i386 which is not the architecture being
linked (x86_64): /Applications/omnetpp-4.3/out/cc_-arch_i386-
release/src/tkenv/tkImgPNG.oignoring file /Applications/omnetpp-4.3/out/cc_-arch_i386-
release/src/tkenv/tkImgPNGInit.o, file was built for i386 which is not the architecture
being linked (x86_64): /Applications/omnetpp-4.3/out/cc_-arch_i386-
release/src/tkenv/tkImgPNGInit.o
Undefined symbols for architecture x86_64:
"_Tkpng_Init", referenced from:
initTk(int, char**) in tklib.o
ld: symbol(s) not found for architecture x86_64
I modified configure.user to use 64 bit architecture.
CFLAGS_DEBUG='-g -Wall -arch x86_64'
CFLAGS_RELEASE='-O2 -DNDEBUG=1 -arch x86_64'
LDFLAGS="-arch x86_64"
However, it looks like that omnet++ just uses 32 bit architecture.
make MODE=release
***** Configuration: MODE=release, TOOLCHAIN_NAME=cc_-arch_i386, LIB_SUFFIX=.dylib ****
How can I build omnet++ as 64 bit architecture?
I needed to add more options.
./configure CFLAG_ARCH='-arch x86_64'
make TOOLCHAIN_NAME=cc_-arch_x86_64
I'm working on OS X 10.6.6 to build a gcc cross-compiler and gnu java for an embedded system. gcc native and cross need to be the same version, so I want to get everything up to the latest gcc version. After building gmp, mpfr, mpc, and binutils with no problem, building native gcc is failing with what I think is the first link step. The specific step that fails is:
fixincludes$ gcc -g -O2 -o fixincl fixincl.o fixtests.o fixfixes.o server.o procopen.o fixlib.o fixopts.o ../libiberty/libiberty.a
ld: warning: in ../libiberty/libiberty.a, file was built for unsupported file format which is not the architecture being linked (x86_64)
Lots of undefined symbol errors follow this warning. libiberty.a and the .o files appear to be the same architecture:
fixincludes$ lipo -info ../libiberty/libiberty.a input file ../libiberty/libiberty.a is not a fat file
Non-fat file: ../libiberty/libiberty.a is architecture: x86_64
fixincludes$ lipo -info *.o
Non-fat file: fixfixes.o is architecture: x86_64
Non-fat file: fixincl.o is architecture: x86_64
Non-fat file: fixlib.o is architecture: x86_64
Non-fat file: fixopts.o is architecture: x86_64
Non-fat file: fixtests.o is architecture: x86_64
Non-fat file: procopen.o is architecture: x86_64
Non-fat file: server.o is architecture: x86_64
I suspect this has to do with 32-bit vs 64-bit, but I don't know what else to check and can't find a specific solution anywhere. Can anyone tell me what's going on here or just nudge me in the right direction?