I am analyzing a swift application that includes several frameworks containing object .o files compiled from Objective-C source files, and the respective headers.
Very few of the methods in the framework libraries are being called so I want to identify what is unused. Is there a tool or linker setting that will do this?
I've found this but it doesn't work for frameworks:
https://github.com/PaulTaykalo/swift-scripts
Thanks.
Related
I have legacy c++ code that I'm trying to re-engineer.
I want to take some part of code out of the project as a ".so" shared library and load them dynamically by "dlopen".
I have written a dynamic loading mechanism which can load new modules dynamically at runtime.
Now I want to decouple existing modules from main project.
For instance I have extracted module "X" from the main project and created shared library which can be loaded later, but some part of the main project are using module X's classes directly and I can't change them yet.
I can compile the project by using module X's header files, but linker throw out "undefined reference" error.
How can I tell c++ linker that these classes will be added later by dlopen mechanism at runtime?
note: I can link and run project by copying created ".so" file of module X in "/lib" folder and use it when linking by "-lX" flag, but if I delete this file form the /lib folder the project fails on startup.
I know if you use X's classes directly you have to link X.so to your program. But if you link X.so you can use dlopen in runtime.
What you need is called an import library. They contain small wrappers for all necessary functions and thus satisfy all static linker dependencies. At runtime these wrappers will load dynamic library if it's not yet loaded and forward execution to real implementation inside library.
Import libraries is a standard feature of Windows DLLs but they are not available out-of-the-box on Linux (or any POSIX system). You can implement wrappers by hand or use Implib.so to generate them automatically.
I'm trying to use scons to build a cross-platform cpp project. Some of the files contain ObjC code, which is only included on OSX and hidden behind ifdef guards on other platforms.
On OSX, I need to include a few -framework compiler/linker options, which I do through
env.AppendUnique(FRAMEWORKS = Split('Cocoa CoreAudio AudioToolbox AudioUnit GLUT OpenGL'))
in my SConstruct file as it says in the docs.
However, the FRAMEWORKS variable only gets used for .m and .mm files, whereas mine all have the .cpp extension. I want to keep it this way, since they're only ObjC files on OSX, and just cpp on other platforms.
Is there a way to get scons to treat source files with a .cpp extension as ObjC++, to get it to use the FRAMEWORKS env var?
I checked the sources of the current version 2.3.4 and there is no support for the FRAMEWORKS variable when compiling source files, only for linking (applelink.py Tool).
So you'd have to define your own ObjC Builder, which then could use the already defined variables like $_FRAMEWORKPATH, $_FRAMEWORKS and $FRAMEWORKSFLAGS.
If you need more help with that, you might want to come over to our user mailing list scons-users#scons.org ( http://www.scons.org/lists.php ) where we could talk you through all the gory details. ;)
I am using Visual Studio 2008 trying to create a .dll. The dll uses an external library (.lib). Compiling and linking works fine (I included the paths to header/lib in the options). When my .dll is used by a program (as a plugin) it says "externalLibrary.dll missing" but there is no externalLibrary.dll, just a externalLibrary.lib.
Are there different options of linking (so the externalLibrary is already in my .dll)? Or can i simply create a .dll from the .lib? Or any other solutions to this problem?
Edit (to be more concrete):
In project properties i added
the header path # C/C++ - General - Additional Include Directories
the library path # Linker - General - Additional Library Directories
the library name # Linker - Input - Additional Dependencies (although
this doesn't change anything)
The .lib file you are using is an import library which basically means that it contains only stubs for functions/classes/... but not the actual implmentation. That implementation is in the dll. An import library is only useful for the linker as it uses it to resolve symbols. But at runtime, the actual compiled code is needed so your application/dll looks for the dll. But even if your dll is used as a plugin, it's no problem for it to depend on other dlls. So if you have the other dll I suggest you go that way. (what is 'externalLibrary' btw?, it's not normal a vendor supplies you only with an import library and not the dll)
If you really do not want to use the external dll, you'll have to find the static library for the code of 'externalLibrary'. Unlike the import library, a static library does contain all symbols complete with actual implementation etc. So after linking with a static library, your application/dll contains the code itself and does not need to resolve it at runtime.
My C++ compiler creates "dylib" files which contain dynamic libraries. Whats the difference between .dylib and .so files?
And what is the difference between files in Mach-O format and files in an ELF format? I have to build files for later use under iOS (static libraries only/Mach-O) and Android (ELF).
Thanx!
I found that:
One Mach-O feature that hits many people by surprise is the strict
distinction between shared libraries and dynamically loadable modules.
On ELF systems both are the same; any piece of shared code can be used
as a library and for dynamic loading. Use otool -hv some_file to see
the filetype of some_file.
Mach-O shared libraries have the file type MH_DYLIB and carry the
extension .dylib. They can be linked against with the usual static
linker flags, e.g. -lfoo for libfoo.dylib. However, they can not be
loaded as a module. (Side note: Shared libraries can be loaded
dynamically through an API. However, that API is different from the
API for bundles and the semantics make it useless for an dlopen()
emulation. Most notably, shared libraries can not be unloaded.) [This
is no longer true—you can use dlopen() with both dylibs and bundles.
However, dylibs still can't be unloaded.]
Loadable modules are called "bundles" in Mach-O speak. They have the
file type MH_BUNDLE. Since no component involved cares about it, they
can carry any extension. The extension .bundle is recommended by
Apple, but most ported software uses .so for the sake of
compatibility. Bundles can be dynamically loaded and unloaded via dyld
APIs, and there is a wrapper that emulates dlopen() on top of that
API. [dlopen is now the preferred API.] It is not possible to link
against bundles as if they were shared libraries. However, it is
possible that a bundle is linked against real shared libraries; those
will be loaded automatically when the bundle is loaded.
To compile a normal shared library on OS X, you should use -dynamiclib
and the extension .dylib. -fPIC is the default.
I'm currently busy on a project where I need to use an external accessory to read Mifare 1k tags.
The accessory was provided with an SDK, written in (Objective ?)C++ and I followed the instructions provided to set XCode to "Compile sources as: Objective-C++" and added "-Obj-C++" in "Other linkers flags.
The SDK compiles fine then, but trouble is I am already using several libraries in the project (such as ASIHTTPRequest, JSONKit, ...) and I get compilation problems because of those new settings in those libraries. If I switch back to the previous settings, I get compilation problems in the reader's SDK
The question is: is there a way to compile only the class from the SDK as C++ and the rest of the project as objective-c ?
Edit: the SDK files consists only of .h (and a linked library)
thanks for your help,
Mike
Select the file you want to compile as Objective C++ from the file navigator, and then select the File Type in the file inspector view. This is in Xcode 4, but there is a similar mechanism in Xcode 3.
Try renaming the files where you are including the library headers to myClass.h for interface and myClass.mm for implementation files. This forces the files to be compiled as objective-c++.
I have resolved this problem:
You should set "According to file type" to "Complile Sources As",
Set "-ObjC++" to the "Other Linker Flags"
The last,you should modify the files's suffix to .mm that reference
the library method
well, in Build phases tab, there is a section Compile sources. For file you want to use Objective-C++ compiler add flag: -xobjective-c++
tested in Xcode 12.5