When I attempt to build grep-2.18 on Mac OS X 10.9.2, make returns
ld: warning: ignoring file libgrep.a, file was built for archive which is not the architecture being linked (x86_64): libgrep.a
Undefined symbols for architecture x86_64:
It then lists what must be inside libgrep.a that got ignored. Please help, This has baffled me for ages.
Also, I'm the sort of person that is fussy and doesn't like using pre-built binaries, so please do not tell me to use MacPorts, Homebrew, etc...
build grep-2.20 with this configuration
./configure --prefix=$PREFIX --build=i386-apple-darwin CFLAGS=-m32
Related
Does anyone know how to do specify the Mac OS X SDK to build against with CMake? I have searched for cmake mac "base sdk" but this turned up nothing.
I am using CMake to generate Unix makefiles.
Update
On my 10.6 install, I see that /Developer/SDKs has the following:
MacOSX10.4u.sdk
MacOSX10.5.sdk
MacOSX10.6.sdk
Perhaps I can get CMake to pass one of these paths to the compiler somehow?
Also, my 10.7 install only has:
MacOSX10.6.sdk
MacOSX10.7.sdk
Does this mean that it can only build for these platforms?
Update 2
Damn, I just realised that actually I'm not using Xcode -- so this may affect some answers. Also, I am now trying with Mac OS X 10.8 developer preview (with some weird results, see my answer).
After trying sakra's valid answer (valid as far as CMake is suposed to behave) unsucessfully, I had a dig around and found that if I specify the --sysroot flag to the compiler, it seems to use the correct SDK!
However, I now see this error when I compile against 10.7 (which I don't see with 10.8):
Undefined symbols for architecture i386:
"_NXArgv", referenced from:
execSelfNonDaemonized() in libarch.a(CArchDaemonUnix.o)
CArchDaemonUnix::daemonize(char const*, int (*)(int, char const**)) in libarch.a(CArchDaemonUnix.o)
ld: symbol(s) not found for architecture i386
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [bin/synergyc] Error 1
make[1]: *** [src/cmd/synergyc/CMakeFiles/synergyc.dir/all] Error 2
make: *** [all] Error 2
Note: CArchDaemonUnix is a class in Synergy (an open source project I'm working on).
Update:
Just tried this on my 10.6 install, and I was getting a linker error when trying to compile for 10.5 -- turns out you also need to specify the MACOSX_DEPLOYMENT_TARGET environment variable!
Anyway, here's what I'm doing when running on Mountain Lion (OSX 10.8) to compile for 10.7:
Command line:
MACOSX_DEPLOYMENT_TARGET=10.7
cmake -G "Unix Makefiles" -DCMAKE_OSX_SYSROOT=/Developer/SDKs/MacOSX10.7.sdk/ -DCMAKE_OSX_DEPLOYMENT_TARGET=10.7 ../..
CMakeLists.txt:
set(CMAKE_CXX_FLAGS "--sysroot ${CMAKE_OSX_SYSROOT} ${CMAKE_CXX_FLAGS}")
I hope this helps someone! :-)
Add the following commands on your CMakeLists.txt
set(CMAKE_OSX_SYSROOT macosx10.10)
set(CMAKE_OSX_DEPLOYMENT_TARGET "10.5")
This should be fine.
You can set the variable CMAKE_OSX_SYSROOT to the chosen SDK upon configuring the project. E.g.:
cmake -DCMAKE_OSX_SYSROOT=/Developer/SDKs/MacOSX10.4u.sdk/ ..
See the documentation here.
Also note that CMake versions before 2.8.8 do not support Xcode 4.3.
I'm trying to build binutils for generating MIPS code on Mac OS X.
I found this site (http://www.theairportwiki.com/index.php/Building_a_cross_compile_of_GCC_for_MIPS_on_OS_X) from How to build GCC 4.8.x on Mac OS X host for MIPS target, and followed the instructions.
I install the gcc-4.8 from brew, and installed source code of binutils and gcc. This is the compilation option setup.
$ export CC=/usr/local/bin/gcc-4.8
$ export CXX=/usr/local/bin/g++-4.8
$ export CPP=/usr/local/bin/cpp-4.8
$ export LD=/usr/local/bin/gcc-4.8
$ export PREFIX=/opt/cross/gcc-mips
$ export CFLAGS=-Wno-error=deprecated-declarations
Then I configure, and make the bintuils.
The issue is that after building static libraries I have an error message that archive is not built for x86_64, and then I have a bunch of undefined symbol error.
ignoring file ./../intl/libintl.a, file was built for archive which is not the architecture being linked (x86_64): ./../intl/libintl.a
Undefined symbols for architecture x86_64:
"__bfd_abort", referenced from:
_fix_new_internal in write.o
_size_seg in write.o
Googling to find that I need to setup AR (archive) variable also from https://github.com/tpoechtrager/osxcross/issues/11. I added export AR=/usr/local/bin/gcc-ar-4.8, but I have another error message because gcc-ar-4.8 doesn't work.
/usr/local/bin/gcc-ar-4.8
/usr/local/bin/gcc-ar-4.8: Cannot find plugin 'liblto_plugin.so'
Googling again to find that gcc-ar doesn't work with Mac OS X (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56893).
gcc-ar is for use with newer GNU binutils only as that is the only ar which supports plugins.
Apple's ar does not support plugins (though it could be made to; it will be a different plugin interface than the GNU BFD
plugin interface which GCC supports right now).
I just created a dumb 'liblto_plugin.so' file in /usr/local/Cellar/gcc48/4.8.4/libexec/gcc/x86_64-apple-darwin14.3.0/4.8.4 directory to suppress the error message, but in this case it looks like that /usr/ar is invoked when I use /usr/bin/gcc-ar-4.8 to get the same architecture and undefined symbols error.
How to solve these issues? How to build cross compiler tools (gcc and binutils) on Mac OS X?
The static library generator for Mac OS X is not ar, but libtool -static. There is another SO post about this - Static library link issue with Mac OS X: symbol(s) not found for architecture x86_64.
The binutils has multiple libraries that are linked statically. So I replaced all the ar rc command with libtool -static -o to get the static libraries that do not cause errors.
In doing so, I had to make two modifications also.
Some library generate libtool script to conflict the Mac OS X's libtool, I had to rename the script.
Some object files do not contain symbols, I had to remove the objects.
Then I could get the binaries without any issue.
Ok so I'm trying to compile my Awesomium go wrapper on my mac (everything works fine on linux). My problem is, when I try to compile I get
ld: warning: ignoring file /Library/Frameworks//Awesomium.framework/Awesomium, file was built for i386 which is not the architecture being linked (x86_64): /Library/Frameworks//Awesomium.framework/Awesomium
Undefined symbols for architecture x86_64:
Fine. But that raises a few questions. First, I didn't have the option to download a x86_64 version for Mac, it was "the mac version" no architecture. Second, I checked a few other libraries and it seems like nothing is built x86_64.
Now I thought maybe I could make a i386 version just for osx but it seems it's extremely difficult, some say impossible, to cross compile cgo.
What are my options?
I'm not sure if you're going to run into any other problems with the universal binary, but building an i386 go toolchain is fairly easy.
http://golang.org/doc/install/source
You can then set the GOHOSTARCH and GOARCH environment variables, e.g.
GOHOSTARCH=386 GOARCH=386 ./all.bash
I'm trying to compile WxWidgets 3.0.2 on my mac OSX 10.10
and I get the following message:
Blockquote
...
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [/Users/.../wxWidgets-3.0.2/build_rel/lib/libwx_osx_cocoau-3.0.0.2.0.dylib] Error 1
I'm compiling using these flags
../configure --with-osx_cocoa --with-macosx-version-min=10.7 --with-macosx-sdk=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk --prefix="$(pwd)" --with-opengl CC=clang CXX=clang++ CXXFLAGS="-stdlib=libc++ -std=c++11" OBJCXXFLAGS="-stdlib=libc++ -std=c++11" LDFLAGS=-stdlib=libc++ --enable-universal-binary=x86_64 --enable-monolithic --enable-unicode --with-expat=builtin --with-zlib=builtin --with-libtiff=builtin --with-regex=builtin --with-libpng=builtin --with-libjpeg=builtin
As you can see I added the enable-universal-binary=x86_64 as suggested in other topics.
If you can suggest other flags that I might have not added or I should remove
that would be great..
Thanks
The other way:
brew install wxwidgets
you will get compiled wxWidgets in /usr/local/Cellar.
In principle, this should work, but what is the point of using --enable-universal-binary=x86_64? It's not universal if there is only a single architecture... You probably wanted to use --enable-macosx_arch=x86_64 instead.
BTW, I think the various stdlib-related options are unnecessary as well, clang is the default compiler under 10.10. And --enable-unicode is definitely superfluous.
If you need wx3.0.0 osx 10.7+ monolitic, shared library can get it from here wxphp stub bundle
Library is included in app/contents/resources , use it if you want. but you need headers c++, get it from wx side.
As posted here, you can use --with-macosx-sdk=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/ as a workaround. There is an fixed issue about it and will probably be released on 3.0.3.
I was attempting to install XML::LibXSLT via CPAN, this seemed to work fine, until I attempted to load Google Chrome, or Microsoft Office. I am getting an error launching these programs with the following errors:
Dyld Error Message:
Library not loaded: /usr/lib/libxslt.1.dylib
Referenced from: /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks
/DictionaryServices.framework/Versions/A/DictionaryServices
Reason: no suitable image found. Did find:
/usr/lib/libxslt.1.dylib: mach-o, but wrong architecture
/usr/lib/libxslt.1.dylib: mach-o, but wrong architecture
Obviously the problem is the new dylibs that XSLT installed, but these all seem to be X86_64 so I shouldn't be seeing any issues with this, I am running Mac OS X 10.6.8.
When running file /opt/local/lib/libxslt.dylib
I get:
/opt/local/lib/libxslt.dylib: Mach-O 64-bit dynamically linked shared library x86_64
as is the same with the libxslt.1.dylib.
Is there a way to solve this issue, and reinstate the original files that must have been replaced?
Edit: If were to get a copy of these Libraries from another Mac 10.6.8 64 bit and replace my apparantly confused ones with these, would this at least solve the issue of them being all mixed up.
Also running
[/usr/lib]$ ls | grep libxslt gives me :
libxslt 2.dylib
libxslt-plugins
libxslt.1.dylib
libxslt.a
libxslt.dylib
libxslt.la
libxslt.pc
Did you install into or otherwise replace the original Apple-supplied libraries in /usr/lib? You should never do that. Otherwise, you'll likely break other parts of OS X that depend on those libraries. You should restore the original libraries from a backup or reinstall OS X. If you want newer versions, you should install them elsewhere, like in /usr/local/lib. Or better yet you should be using a third-party package manager, like Homebrew or MacPorts; in fact, you appear to be using MacPorts, judging from the /opt/local/lib path. Use that and don't alter system files in /usr (other than /usr/local) or /System/Library.
This may be relevant: How to compile universal binaries on Mac OS X.
I ran into this same issue where I had re-compiled libxslt and libxml to support python bindings, then started getting the /usr/lib/libxslt.1.dylib: mach-o, but wrong architecture error and an immediate crash when starting some apps (Specifically Synergy, which is a 32-bit/i386 app)
I solved this by recompiling libxml2 and libxslt using these configure options:
./configure CFLAGS="-arch i386 -arch x86_64" \
CXXFLAGS="-arch i386 -arch x86_64" \
LDFLAGS="-arch i386 -arch x86_64" \
--disable-dependency-tracking
Now libxml2 and libxslt libraries are properly showing as universal binaries:
$ file /usr/local/lib/libxslt.1.dylib /usr/local/lib/libxslt.1.dylib: Mach-O universal binary with 2 architectures
/usr/local/lib/libxslt.1.dylib (for architecture i386): Mach-O dynamically linked shared library i386
/usr/local/lib/libxslt.1.dylib (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64
$ file /usr/local/lib/libxml2.2.dylib
/usr/local/lib/libxml2.2.dylib: Mach-O universal binary with 2 architectures
/usr/local/lib/libxml2.2.dylib (for architecture i386): Mach-O dynamically linked shared library i386
/usr/local/lib/libxml2.2.dylib (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64