I am experiencing what seems to be the same problem when I try to compile two different programs. Each of them creates first a static library and then the main application linking that library. I am working on Mac OS Mavericks with gcc 4.7.2.
Program 1
This is what is happening when I run make:
First, the library libfeat.a is created, but I get a warning:
ar rc ../lib/libfeat.a imgfeatures.o utils.o sift.o kdtree.o minpq.o xform.o
ranlib ../lib/libfeat.a
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: warning for library: ../lib/libfeat.a the table of contents is empty (no object file members in the library define global symbols)
Then, when compiling the application, it says that it cannot use the library because it wasn't built for the same architecture (x86_64):
gcc -O3 -I../include `pkg-config --cflags opencv` `pkg-config --cflags gtk+-3.0` `pkg-config --cflags gsl` siftfeat.c -o ../bin/siftfeat -L../lib -lfeat `pkg-config --libs opencv` `pkg-config --libs gtk+-3.0` `pkg-config --libs gsl`
ld: warning: ignoring file ../lib/libfeat.a, file was built for archive which is not the architecture being linked (x86_64): ../lib/libfeat.a
If I run lipo, I get this:
$ lipo -info ../lib/libfeat.a
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/lipo: archive with no architecture specification: ../lib/libfeat.a (can't determine architecture for it)
Program 2
I am experiencing the same problem with a different program that does the same: creating a library first and using it later.
This is the output when creating the lib:
ar crv libsba.v1.5.a sba_levmar.o sba_levmar_wrap.o sba_lapack.o sba_crsm.o sba_chkjac.o
r - sba_levmar.o
r - sba_levmar_wrap.o
r - sba_lapack.o
r - sba_crsm.o
r - sba_chkjac.o
ranlib libsba.v1.5.a
This is the application:
c++ -o bundler -O3 -Wall -fpermissive -I../lib/imagelib -I../lib/sfm-driver -I../lib/matrix -I../lib/5point -I../lib/sba-1.5 -I../lib/ann_1.1_char/include -L../lib -L../lib/ann_1.1_char/lib \
-D__NO_UI__ -D__BUNDLER__ -D__BUNDLER_DISTR__ BaseApp.o BundlerApp.o keys.o Register.o Epipolar.o Bundle.o BundleFast.o MatchTracks.o Camera.o Geometry.o ImageData.o SifterUtil.o BaseGeometry.o BundlerGeometry.o BoundingBox.o BundleAdd.o ComputeTracks.o BruteForceSearch.o BundleIO.o ProcessBundle.o BundleTwo.o Decompose.o RelativePose.o Distortion.o TwoFrameModel.o LoadJPEG.o -limage -lsfmdrv -lsba.v1.5 -lmatrix -lz -llapack -lblas -lcblas -lminpack -lm -l5point -ljpeg -lANN_char -lgfortran
ld: warning: ld: warning: ignoring file ../lib/libsba.v1.5.a, file was built for archive which is not the architecture being linked (x86_64)
In this case, lipo does tell me that the architecture of the library is x86_64:
$ lipo -info lib/libsba.v1.5.a
input file lib/libsba.v1.5.a is not a fat file
Non-fat file: lib/libsba.v1.5.a is architecture: x86_64
What's going on?
A possible cause is using the GNU ar(1)/ranlib(1) instead of the ones supplied by the Xcode toolchain. Run which -a ar and which -a ranlib to see the what you have in $PATH.
For example:
$ which -a ranlib
/usr/local/bin/ranlib
/usr/bin/ranlib
$ /usr/local/bin/ranlib --version
GNU ranlib (GNU Binutils) 2.28.51.20170105
Copyright (C) 2017 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) any later version.
This program has absolutely no warranty.
$ /usr/bin/ralib --version
error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: unknown option character `-' in: --version
Usage: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib [-sactfqLT] [-] archive [...]
Same for ar. If you're like me and had /usr/local/bin preceeding /usr/bin in $PATH, with the GNU tools in /usr/local/bin and the Xcode ones in /usr/bin, you can fix it with:
cd /usr/local/bin
mv ar gar
ln -s /usr/bin/ar ar
mv ranlib granlib
ln -s /usr/bin/ranlib ranlib
Thanks to this question with the same problem, I could look into this problem. I don't have much experience with static libraries, but I'll try to explain the problem.
For some reason, Mac OSX ar utility creates "subdirectories" in the static library. For example, building the sba library, the steps of make to build the static library from the object file is:
ar crv libsba.v1.5.a sba_levmar.o sba_levmar_wrap.o sba_lapack.o sba_crsm.o sba_chkjac.o
After that, if I look at the contents of the static library, I saw that in addition to the files, there are some strange directorios:
$ ar -t libsba.v1.5.a
__.SYMDEF
/
//
sba_levmar.o/
/0
sba_lapack.o/
sba_crsm.o/
sba_chkjac.o/
sba_levmar.o
sba_levmar_wrap.o
sba_lapack.o
sba_crsm.o
sba_chkjac.o
sba_levmar.o
sba_levmar_wrap.o
sba_lapack.o
sba_crsm.o
sba_chkjac.o
If we try to extract those files, we get some errors regarding the subdirectories:
$ ar -x libsba.v1.5.a
ar: /: Is a directory
ar: //: Is a directory
ar: sba_levmar.o/: Not a directory
ar: /0: Permission denied
ar: sba_lapack.o/: Not a directory
ar: sba_crsm.o/: Not a directory
ar: sba_chkjac.o/: Not a directory
Now, if we create the lib again with the extracted object files, it will work:
$ ar crv libsba.v1.5.a lib_o/*.o
a - lib_o/sba_chkjac.o
a - lib_o/sba_crsm.o
a - lib_o/sba_lapack.o
a - lib_o/sba_levmar.o
a - lib_o/sba_levmar_wrap.o
$ ar -t libsba.v1.5.a
__.SYMDEF SORTED
sba_chkjac.o
sba_crsm.o
sba_lapack.o
sba_levmar.o
sba_levmar_wrap.o
I don't understand the reason at all, but it worked for me.
Using libtool -static -a might be simpler to get working static library.
Static library link issue with Mac OS X: symbol(s) not found for architecture x86_64
If you have binutils installed just unlink or uninstall it
brew unlink binutils
I had the problem of getting the wrong architecture error message. It said the following:
ld: warning: ignoring file blah/lib/blahblah.a, file was built for archive which is not the architecture being linked (i386)
lipo gives: Non-fat file: ../lib/blahblah.a is architecture: x86_64
in the makefile it said the following: ARCH_FLAG = -arch x86_64 -arch i386
I commented out the i386 part and the error disappeared. ARCH_FLAG = -arch x86_64 #-arch i386
So, I think it is possible you are getting the error for the same reason. Maybe you just need to set the architecture class to match your library.
By the way, my makefile was generated by swig, and I had not set any switches for the compiler.
来源：https://stackoverflow.com/questions/22107616/static-library-built-for-archive-which-is-not-the-architecture-being-linked-x86