How to create static library for iOS without makin

2020-05-19 03:03发布

问题:

This question has been asked before, but digging into the documentation for the various development tools it seems like this is possible, just not obvious.

Motivation: Making a static library for use by other iOS developers. Some symbols in the library will cause problems if exported so I wish to make them internal-only symbols. With a dynamic library this is easy, just use -exported_symbols_list libtool (ld) argument and list the ones you want public. libtool documentation will not allow this argument for static libraries.

Library has several ObjectiveC .m files that use code from each other. Only one class in the group needs to be made public to users of the final .a static library file.

Tried libtool -exported_symbols_list publicsymbols.exp but that argument to libtool is not supported with -static for static libraries.

Can't make the symbols private with attributes (if that'd even work) because they are needed by the other .m files in the group.

looks like ld can take several .o files and link them together into a new .o file (via the -r argument) and it doesn't have the "dynamic only" disclaimer for the -exported_symbols_list argument (which could just be unclear documentation...).

just as a test I build my project with Xcode so I have all the .o files made, and then try to call ld on the command line, like so:

ld -r -x -all_load -static -arch armv6 -syslibroot {path} 
   -filelist /Users/Dad/ABCsdk/iphone-ABClib/build/ABCLib.build/Distribution-iphoneos/ABCLib-device.build/Objects-normal/armv6/ABCsdk.LinkFileList 
   -exported_symbols_list {exp file path} -o outputfile.o

where the {path} type things have long paths to the appropriate places in there.

but I get errors like the following:

/usr/bin/ld_classic: /Users/Dad/ABCsdk/iphone-ABClib/build/ABCLib.build/Distribution-iphoneos/ABCLib-device.build/Objects-normal/armv6/ABCmain.o incompatible, file contains unsupported type of section 3 (_TEXT,_picsymbolstub4) in load command 0 (must specify "-dynamic" to be used)

so something seems wrong there...

Anyone know a clever way to make this work? Thanks.

回答1:

This is really not possible, I'm sorry to say. It has to do with the way static libraries work. A static library is little more than a bunch of object *.o files bundled together, but a dynamic library is a loadable binary image, just like an executable.

Suppose you have four files,

  • common.c defines common, which is "private"
  • fn1.c defines fn1, which calls common.
  • fn2.c defines fn2, which calls common.
  • other.c defines other.

In a dynamic library, the linker bundles everything up into one big chunk of code. The library exports other, fn1, and fn2. You have to load the entire library or none of it, but two programs can both load it without putting multiple copies in memory. The entry point to common is simply missing from the symbol table — you can't call it from outside the library because the linker can't find it.

Note that an application and a shared library have essentially the same format: an application is basically a shared library that only exports one symbol, main. (This is not exactly true, but close.)

In a static library, the linker never runs. The files all get compiled into *.o files and put into a *.a library archive. Internal references will be unresolved.

Suppose your application calls fn1. The linker sees an unresolved call to fn1, and then looks through the libraries. It finds a definition for fn1 in fn1.o. Then the linker notices an unresolved call to common, so it looks it up in common.o. This program won't get the code from fn2.c or other.c, because it doesn't use the definitions from those files.

Static libraries are very old, and they do not have any of the features of dynamic libraries. You can think of a static library as basically a zip file full of compiled source code, unlike a dynamic library which is linked together. Nobody ever bothered to extend the archive format to add symbol visibility. When you link with a static library, you get the same result as if you had added the library's source code to your program.

The short version: A dynamic library has one symbol table of all of the exported symbols, but none of the private symbols. In the same way, an object file has a list of all of its extern symbols but none of the static ones. But a static library has no symbol table, it is just an archive. So there is no mechanism to make code private to a static library (other than defining objects static, but that doesn't work for Objective-C classes).

If we knew why you were trying to do this, perhaps we could give you a suggestion. (Is it for security? Name clashes? All of these questions have solutions.)



回答2:

XCode BuildSetting can do this! 1. Set Perform Single-Object Prelink to YES 2. Set Exported Symbols File to path_for_symbols_file

maybe you should remove -static, -exported_symbols_list can not work static lib, but can take effect on object file.