I have a set of iPhone static libraries (a *.a file) in which I only call a few of the classes from.
I have used AR in the past (with linux libraries) to extract the object files from the static library, remove the unwanted object files and rearchive.
However, when I try this with an iPhone compliled static library, I get the following error:
ar: CustomiPhoneLib.a is a fat file (use libtool(1) or lipo(1) and ar(1) on it)
ar: CustomiPhoneLib.a: Inappropriate file type or format
Does anyone know how to extract the object files from an iphone compiled static library? Doing thie could potentially reduce the final file size.
That’s because your CustomiPhoneLib.a is a fat library, i.e., a library that contains more than one target architecture, namely armv6 and armv7 on iOS. You can use lipo to extract a specific architecture into another .a file, use ar and ranlib to manipulate it at will, and then use lipo again to recombine the manipulated .a files into a single .a fat file. For instance,
lipo CustomiPhoneLib.a -thin armv6 -output CustomiPhoneLibarmv6.a
lipo CustomiPhoneLib.a -thin armv7 -output CustomiPhoneLibarmv7.a
### use ar and ranlib at will on both files
mv CustomiPhoneLib.a CustomiPhoneLib.a.original
lipo CustomiPhoneLibarmv6.a CustomiPhoneLibarmv7.a -create -output CustomiPhoneLib.a
However, you don’t have to do this for the reason you’ve mentioned. The linker will only pull object (.o) files from a library (.a) if it needs to resolve some symbol reference. Therefore, if a library contains an object file whose symbols are never referenced during the linking process (i.e., symbols that are not effectively used), that object file won’t make it into the executable.
Code:
ar -t mylib.a
This will list all of the files in the archive.
Code:
ar -xv mylib.a myobj.o
This will extract the object give myobj.o from the library mylib.a.
Related
I have to merge one of my app's libs with the NVIDIA CUDA static lib using this horrific awful CMake code:
GET_TARGET_PROPERTY(OUTPUT_LIB ${LIBNAME} LOCATION)
add_custom_command (TARGET ${LIBNAME}
POST_BUILD
COMMAND mv ${OUTPUT_LIB} ${OUTPUT_LIB}.old
COMMAND echo "create ${OUTPUT_LIB}" > combineLibs.mri
COMMAND echo "addlib ${OUTPUT_LIB}.old" >> combineLibs.mri
COMMAND echo "addlib ${CUDA_LOCATION}" >> combineLibs.mri
COMMAND echo "save" >> combineLibs.mri
COMMAND echo "end" >> combineLibs.mri
COMMAND ar -M <combineLibs.mri
COMMAND rm ${OUTPUT_LIB}.old
COMMENT "Building merged library for ${LIBNAME} at ${OUTPUT_LIB}, including ${CUDA_LOCATION}"
)
target_link_libraries(${LIBNAME} -pthread -c)
This successfully produces a merged static library that has all the symbols in it. However, the NVIDIA CUDA static lib brought with it dependencies on libpthread and libc in the form of unresolved symbols. Now the merged library also has those unresolved symbols, and the target_link_libraries line doesn't seem to do what I seem to think it does, because the symbols don't get resolved at link-time. How do I get the merged static library to dynamically link against libpthread and libc?
The the target_link_libraries line does indeed not do what you think.
target_link_libraries(target,options) can have the desired effect of
adding the linker options options to the linkage of target only if target
is something that is produced by the linker. If no linkage happens in the
production of target then this directive will have no effect.
Your target is a static library. A static library - unlike a program, and unlike
a dynamic/shared library - is not produced by the linker. As your custom_command
in fact illustrates, a static library is produced by the GNU general purpose archiver,
ar. It is nothing but an archive of files which happen to be object files,
but as far as ar is concerned they might as well be the contents of your
Documents, Pictures and Music folders. Since no linkage is involved in the
production of a static library, nothing can be linked with a static library.
An ar archive can be used as a linker input in the linkage of something that
is produced by the linker - a program or a shared library. In that case the
linker will look into the archive to see if contains any object files it needs
to carry on the linkage. If it finds any, it will extract them from the archive
and link them into the program. The linkage will be exactly the same as if
you had listed the required object files in the linker commandline and not
mentioned the archive at all.
But if any of the object files that the linker extracts from an archive bring
with them undefined references, then to get them resolved you must link some
library or libraries that define those references in the linkage of the
program or shared library that you want the linker to produce - just as you
must do to resolve undefined references in any other object files you
input to the linkage.
So,
How do I get the merged static library to dynamically link against libpthread and libc?
You can't. It doesn't make sense. Any library dependencies of object files
in a static library can be satisfied only in the linkage of a program or shared library
that has acquired those dependencies by linking those object files.
Finally, -c is not a GCC linkage option that will have the effect of requesting
linkage of libc. It is not a linkage option at all. It is an option that
directs the GCC frontend not to invoke the linker. It is passed to GCC to
request compilation without linkage, and the perverse effect of including it in a
CMake target_link_libraries directive will be to stop any linkage of the
target from happening.
If you want to explicitly request linkage of libc, use -lc, following
the linker usage protocol that -lname requests linkage of libname.
Perhaps you inferred that -c requests linkage of libc from the assumption
that -pthread requests linkage of libpthread. In fact, -lpthread would
request linkage of libpthread. The option -pthread is a more abstract GCC
option, for both compilation and linkage, that means do the right things, for this platform, to link with the Posix Threads
library - which might entail passing -lpthead to the linker, and possibly not.
Thus -pthread is OK as an argument of target_link_libraries that will
have the effect of requesting Posix Threads linkage, but see
answers to cmake and libpthread
for CMake-proper ways of doing this.
I use Eclipse + ARM plugin to build my projects. When I needed to use in my project the StemWin library, I configured my IDE to use external library.
I set
Preferences -> C/C++ General -> Paths and Symbols
I added in "Library Paths" the link to my folder includes library.
I also added the name of my library in tab "Library".
I checked the settings in the compiler tab and I ascertained all should be good.
When I tried to build my project I got an error from linker:
cannot find -lMyLib.a Hello C/C++ Problem
I double checked the name of my library and link, all are correct. This is the output of my linker:
arm-none-eabi-gcc -mcpu=cortex-m4 -mthumb -mfloat-abi=hard -L"C:\lib"
-T"C:\arm_toolchain\stm32_workspace\Hello\LinkerScript.ld" -Wl,
-Map=output.map -Wl,--gc-sections -o "Hello.elf" #"objects.list" -lMyLib.a
What should I do from here?
I faced the same problem before.
-l:STemWin526_CM4_GCC.a
-L"C:\Edu_Workspace\STM32F4\stm32f4_bsp_template\Drivers\Middlewares\ST\STemWin\Lib"
Above are my working settings.
With -l:<archive file name> the colon : is important for archive file linking.
And -L will contain library path.
Also for stemwin make sure to compile with hardware floating point
-mfloat-abi=hard -mfpu=fpv4-sp-d16
the convention for the -l option of the linker (say you give -lMyLib.a as a linker option) is to search for a library file with "lib" prepended to the given name and .a (or .so) appended, i.e. your command line searches for a file libMyLib.a.{a,so} which is probably not how it's named.
Either you rename your library according to this convention or give it to the linker command line omitting -l (provided your IDE allows you to do so).
Looks like the problem is in -lMyLib.a which means you're trying to link a static library as a dynamic one.
To link a static lib you have to use its path as with ordinary .o files: ... /path/to/MyLib.a
and the resulting command line should look something like
arm-none-eabi-gcc -mcpu=cortex-m4 -mthumb -mfloat-abi=hard -L"C:\lib" -T"C:\arm_toolchain\stm32_workspace\Hello\LinkerScript.ld" -Wl,-Map=output.map -Wl,--gc-sections -o "Hello.elf" #"objects.list" /path/to/MyLib.a
UPDATE:
Although it might fix the issue, turns out it's not true:
-llibrary
-l library
...
Normally the files found this way are library files—archive files whose members are object files. The linker handles an archive file by scanning through it for members which define symbols that have so far been referenced but not defined. But if the file that is found is an ordinary object file, it is linked in the usual fashion. The only difference between using an -l option and specifying a file name is that -l surrounds library with ‘lib’ and ‘.a’ and searches several directories.
(https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html)
I have two files: Main.d and ImportMe.d. Their purposes should be self-explanatory. They are in the same directory, and have no explicit module declaration. When I try to compile Main.d, though, I get a "symbols not found" error!
$ dmd Main.d -I.
Undefined symbols:
"_D8ImportMe12__ModuleInfoZ", referenced from:
_D4Main12__ModuleInfoZ in Main.o
"_D8ImportMe8SayHelloFxAyaZv", referenced from:
__Dmain in Main.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
--- errorlevel 1
Compiling both files at the same time works fine.
$ dmd Main.d ImportMe.d
You don't have to do this with the standard library, though. What is it doing differently? Changing the include path via -I has no visible effect.
When you compile a module, dmd must have the .d or .di files for all of the modules that that module needs in its import path. -I allows you to add paths to the import path. However, that does not build those other modules. It just gives dmd what it needs to build the module that you requested it to build. And when you link, dmd needs either the object files or the library binaries for all of the modules being used in the program, otherwise it's going to complain about undefined symbols (-L can be used for linker flags if you want to link in libraries). The linking step uses the C linker, so it's not D-aware at all and doesn't know anything about modules.
So, if you compile and link in two steps, you first compile each module separately or together with other modules, generating either object files or library files, depending on the flags that you pass the compiler (object files are the default). You then link those object files and libraries together in the linking stage, generating the executable.
When you use dmd without passing it -c or -lib, it's going to do both the compiling and the linking together, so you must provide it all of the modules that you intend to compile, or when it gets to the linking step, it's going to complain about undefined symbols. It doesn't magically go and compile all of the modules that the modules that you ask it to compile import. If you want that sort of behavior, you need to use a tool such as rdmd.
dmd is able to find druntime and Phobos without you having to specify them because of dmd.conf (on Posix) or sc.ini (on Windows). That configuration file adds the appropriate .d and .di files to the import path and adds libphobos.a or phobos.lib (depending on the platform) to DFLAGS so that dmd can find those modules when compiling your modules and can link in the library in the linking phase. It also adds in any other flags that the standard library needs to work (such as linking in librt on Linux). If you move any of those files to non-standard places, it's that configuration file that you need to change to make it so that dmd can still find them.
You don't have to specify modules from the standard library because the compiler implicitly passes the precompiled standard library .lib file to the linker. For your own projects, consider using rdmd or another build tool.
I have a FAT .a archive on my Mac (a library) and I just wanted to know how I could extract the files from it?
lipo input_file -extract architecture -output output_file
This is for extracting a single architecture of a Universal Binary archive. Not sure if this helps, though.
I have compiled tesseract for using it in xcode following: http://iphone.olipion.com/cross-compilation/tesseract-ocr
I obtain the .a file, import it as framework in the iphone project, and update the header search path for tesseract header files.
So now I need a simple example in order to get start.
I can't find anything in http :// code.google.com/p/tesseract-ocr/ or by googling.
Anyone can help me give me a starting point (a code snippet)..?!
Many ThankS!
--
Later i found this code:
#include "baseapi.h"
TessBaseAPI::InitWithLanguage(NULL, NULL, language, NULL, false, 0, NULL);
char* text = TessBaseAPI::TesseractRect(imagedata, bytes_per_pixel,
bytes_per_line, 0, 0,
width, height);
TessBaseAPI::End();
but when I try to compile for device (only inserting include statement without the code above) i get the following:
error:syntax error before 'PAGE_RES'
warning:type defaults to 'int' in declaration of 'PAGE_RES'
warning:data definition has no type or storage class
and so on with BLOCK_LIST, IMAGE etc.
if compile for simulator i get
error: expected '=',',',','asm' or 'attribute' before 'PAGE_RES'
and so on with BLOCK_LIST, IMAGE and TessBaseAPI
--- Other Update:
I found solution for include problem:
Where the include occurs must be rename the file.m in .mm extension because we have to tell xcode that we have to use objective-c and c++ together.
http://github.com/nolanbrown/Tesseract-iPhone-Demo
OCRDemo is a demo application that utilizes the Tesseract library (http://code.google.com/p/tesseract-ocr/) as a static library compiled under Mac OS 10.6 using the shell script found at http://robertcarlsen.net/2009/07/15/cross-compiling-for-iphone-dev-884.
The program is only meant to provide a demonstration of the OCR library and it’s abilities on the iPhone, the program is not optimized in any way...
you'll need to update SDKROOT, CPPFLAGS and CXX
variables. For example, here's the relevant part of my build script,
modified to work with 4.0:
export SDKROOT=$DEVROOT/SDKs/iPhoneOS4.0.sdk
export PATH=$DEVROOT/usr/bin:$PATH
# Set up relevant environment variables
export CPPFLAGS="-I$SDKROOT/usr/lib/gcc/arm-apple-darwin10/4.0.1/
include/ -I$SDKROOT/usr/include/ -miphoneos-version-min=4.0"
export CFLAGS="$CPPFLAGS -arch armv6 -pipe -no-cpp-precomp -isysroot
$SDKROOT"
export CPP="$DEVROOT/usr/bin/cpp $CPPFLAGS"
export CXXFLAGS="$CFLAGS"
Dynamic library location generated by the Unix package
LIBPATH=$LIBFILE.dylib
LIBNAME=`basename $LIBPATH`
export LDFLAGS="-L$SDKROOT/usr/lib/ -Wl,-
dylib_install_name,#executable_path/$LIBNAME"
Static library that will be generated for ARM
LIBPATH_static=$LIBFILE.a
LIBNAME_static=`basename $LIBPATH_static`
# TODO: add custom flags as necessary for package
./configure CXX=$DEVROOT/usr/bin/arm-apple-darwin10-g++-4.0.1 CC=
$DEVROOT/usr/bin/arm-apple-darwin10-gcc-4.0.1 LD=$DEVROOT/usr/bin/ld --host=arm-apple-darwin