I built universal static library with help of this template
The problem that is my library libWrapper.a has size 1.3 mb??? :0
while my source code has 130 kb.
How I can reduce the size of my static lib?
Other strange thing -
Each lib has the same size - 1.3 mb. I supposed that universal (fat) libs should have bigger size.
Also make sure that you set Generate Debug Symbols to NO in your build settings. This can reduce the size of your static library by about 30%.
in terminal run
strip -x [youStaticlib.a]
Description
For dynamic shared libraries, the maximum level of stripping is usually
-x (to remove all non-global symbols).
if you want to know strip other parameter, in terminal run
man strip
You cant. Static libraries include all the code that they reference in the form of frameworks inside their executable.
Related
I have a Fortran code which has been made to work on CPUs, but I need to accelerate it using GPUs and I chose to do that with OpenACC.
This code uses FFTW libraries when compiled with gfortran. However, as you may know, these libraries cannot be used with nvfortran. So, I have to go with cufft libraries.
Therefore, I used this conversion giude. The problem is, fftw allows users to build a Fortran module with iso_c_binding including the file fftw.f, while cufft does not have this kind of feature and you need to include the cufft.h header.
When compiling with nvfortran (I use -cpp, -Mfree, -lcufft and -l cufftw flags, checked the include and lib directories given to -I and -L flags) I get many errors:
The paths in all the #include inside the cufft.h file are wrong and I had to change them manually
All the comments ("//") in the header files are seen as errors (had to remove them manually)
“Label field of continuation line is not blank” errors everywhere in header files, starting from line 2 (in lines 1 I solved that giving 7 spaces - but didn’t I use -Mfree for that?)
Please help me, I don’t think that the right way to do so is to change files manually…
Thanks in advance for helping
You cannot include headers for the C programming language in Fortran source code. Instead use the Fortran interfaces to any libraries you need (provided such interfaces exist).
We ship a cuFFT interface module with the compilers. You should just be able to add "use cufft".
Full documentation can be found at: https://docs.nvidia.com/hpc-sdk/compilers/fortran-cuda-interfaces/index.html#cf-fft-runtime
Example codes are shipped with the NVHPC SDK which can be found in the "<INSTALL_DIR>/Linux_x86_64/<RELEASE>/examples/CUDA-Libraries/cuFFT/"" directory
Original questin: Is there any way to get what macros nw-gyp add to the build project by default?
I'm developing a nw addon and I've tried to link a custom static lib to .node DLL. However I found nw-gyp will add _HAS_ITERATOR_DEBUGGING=0 by default (It always appends to the addon project to override custom defines), which will affect the actual structure size for STL types (e.g. std::string).
So is there a way to get such macros node gyp added by default, or is there an easy way to make compiler's (maybe the whole toolchain, link tool etc.) configuration for both static lib and nw build project the same?
Now I've add _HAS_ITERATOR_DEBUGGING=0 to my lib and make it MT(D), and It seems to work fine, but I'm not sure if this is the right way. (Some other compiler settings may not cause compilation error but can crash in runtime)
Edit: Share some analysis to make my origin question clearer.
All current question is on Windows platform.
The _HAS_ITERATOR_DEBUGGING=0 is added even when I build nw addon in debug mode (with --debug), and this may be affected by the nw headers downloaded by nw-gyp. For example, headers download from http://node-webkit.s3.amazonaws.com/v0.49.2/nw-headers-v0.49.2.tar.gz , you will find 'defines': [ 'DEBUG', '_DEBUG', 'V8_ENABLE_CHECKS', '_HAS_ITERATOR_DEBUGGING=0' ] in common.gypi at line 288 in Debug_Base config section, and this is most likely inherit from https://github.com/nwjs/chromium.src (I guess here https://github.com/nwjs/chromium.src/blob/nw60/build/config/BUILD.gn#L130). So can it be concluded that Chrome add these defines for debug mode on purpose?
What is the problem _HAS_ITERATOR_DEBUGGING=0 in debug for me? Well, it affects the size for many STL classes (std::string, std::vector and etc.). So all debug lib that need to be linked to nw addon should be compiled with '_HAS_ITERATOR_DEBUGGING=0', otherwise compilation error will occur for static libs and runtime pointer problem crash (struct offset mismatch) for dynamic libs (of course it is not a good practice to use STL in dynamic lib headers, but if you can assume the toolchain same it will still work fine). But this is really hard for me when it comes to third-party binaries, I've got no sources for most of them, so I can't give a debug static lib with _HAS_ITERATOR_DEBUGGING=0 on. This is really frustrating when I need to debug the addon with lldb or VS, since all variables are optimized and you cannot debug their values.
Can I force _HAS_ITERATOR_DEBUGGING=1 for debug mode? As mentioned in origin question, it cannot be done normally like answer from #mmomtchev. A hack way to do is to add "/D _HAS_ITERATOR_DEBUGGING=1" to configurations->Debug->msvs_settings->VCLinkerTool->AdditionalOptions in gyp file for addon, this will append /D _HAS_ITERATOR_DEBUGGING=1 to the end of the compile command which override the former defination. But I'm not sure if this is a good workaround! I've checked v8 header files and have found some classes with std::string and std::vector members. I think force _HAS_ITERATOR_DEBUGGING will cause some problem if you use these classes, but for other classes it is safe (I've tested many cases, normal classes like v8::value v8::function work well). And it is not safe when cooperating with other addons. Let's assume one debug addon A and another release addon B need to communicate with each other, they agree on one C++ struct for data exchange. A common way is to let A to wrap a C++ struct instance to a JS object for user. and let user pass the JS object to B by calling methods provided by B (the JS object is one of the arguments), and then B unwrap the JS object from arguments and get the pointer of the C++ struct instance. All looks fine, but what if the C++ struct has std::string member? The sizes of same C++ struct for A and B are not the same. so B will crash when trying to access the member with type of std::string or std::vector. This is not an issue if _HAS_ITERATOR_DEBUGGING=0 is set for debug mode since _HAS_ITERATOR_DEBUGGING is always disabled for release, and I guess that's why nw addon can work with mixed production mode(debug an release) addons in common cases.
So my final question is: If it is not a good way to force _HAS_ITERATOR_DEBUGGING=1 for debug and I don't have source code for many external compiled lib binaries, does it mean I've no way to build a nw addon in debug mode? Athother possible way is to wrapper those libs with C style API and compile them to dynamic libs, but this is really huge work for me and is unacceptable.
Normally, _HAS_ITERATOR_DEBUGGING=0 is defined by default on all Release builds.
If you need to add macros, you need to add this section to the root of your gyp:
'defines': [ '_HAS_ITERATOR_DEBUGGING=0' ]
I'm looking for a fast way to check if a ELF binary is a shared object or a position independent executable. I think a can do that by checking the contained symbols / functions. I'm looking for a more efficient way of not having to read the complete file. I have to perform the check on different platforms, at least Android, Linux (32 and 64 bit).
I'm looking for a fast way to check if a ELF binary is a shared object or a position independend executable.
There is no way to check: a PIE executable is a shared object.
I think a can do that by checking the contained symbols / functions.
Symbols can be stripped, and once they are, you can't tell.
shared objects and executables they normally differ by the linked startup code
That's true: the PIE is normally linked with Scrt1.o, but a shared library is normally not. But there is nothing to prevent a shared library to be linked with Scrt1.o as well, and in a stripped binary even finding that startup code may be somewhat problematic.
If what you really want is to distinguish between a shared library and a PIE executable which you built yourself (rather than solving a general case of any shared library and any PIE), then checking for presence of PT_INTERP (readelf -l a.out | grep INTERP) is likely the easiest way to go: a PIE executable is guaranteed to have PT_INTERP, and shared libraries normally don't have it (libc.so.6 is a notable exception).
Try the elfutils and the included program eh-readelf:
eh-readelf --file-header $ELFFILE
showw you the file header and what kind of file it is:
...
Typ: EXEC (Executable file)
...
or
Typ: DYN (Shared object file)
In combination with a little sed line you should get the results you want.
Does small embedded system without RTOS/OS uses dynamic/shared libraries. my understanding is that its very tough to use it and will be not productive.
If we are calling an API multiple times which is present in a static library. Does API code will be placed at every call location like macro expansion or code/text will be common for all calls. I think code/text will be common.
If I have made a static library for a .c files which has multiple API's and I am statically linking it with main file and in main file only one API has been called so my question is does whole library is included in final .bin or only particular API code.
from above questions you can assume that I am missing fundamentals itself so can anyone please provide the related links to brush up these.
Regards
[edit]
I have tried following things
addition.c module
`int addition(int a,int b)`
`{`
`int result;`
`result = a + b;`
`return result;`
`}`
`size addition.o`
23 0 0 23 17 addition.o
multiplication.c module
`int multiplication(int a, int b)`
`{`
`int result;`
`result = a * b;`
`return result;`
`}`
`size multiplication.o`
21 0 0 21 15 multiplication.o
created object file of both and put in archieve
ar cr libarith.a addition.o multiplication.o
then statically linked to my main application
example.c module
`#include "header.h"`
`#include <stdio.h>`
`1:int main()`
`2:{`
`3:int result;`
`4:result = addition(1,2);`
`5:printf("addition result is : %d\n",result);`
`6:result = multiplication(3,2);`
`7:printf("multiplication result is : %d\n",result);`
`8:return 0;`
`9:}`
gcc -static example.c -L. -larith -o example
size of example
511141 1928 7052 520121 7efb9 example
commented line number 6 of example.c
and again linked
gcc -static example.c -L. -larith -o example
size of example
511109 1928 7052 520089 7ef99 example
32 bytes of difference between above two
thats mean addition.o is not included in example
merged both modules addition.c and multiplication.c as addmult.c as below
int addition(int a,int b)
{
int result;
result = a + b;
return result;
}
int multiplication(int a, int b)
{
int result;
result = a * b;
return result;
}
created object file and put in archieve
before doing that i have deleted previous archieve
ar cr libarith.a addmult.o
now commented line number 6 of example.c
gcc -static example.c -L. -larith -o example
size example
511093 1928 7052 520073 7ef89 example
uncommented line nmber 6 of example.c
size example
511141 1928 7052 520121 7efb9 example
My question is in both cases if both functions are called final text size is same but if only one function is called then there is difference of 16
but multiplication.o size is 23 so definitly it has been not included but how we will justify 16.
If i am missing some fundamental itself ?
To dynamically load and link a library at runtime requires code to perform the load/link operation. That capability is normally part of an operating system. Moreover in a system without mass-storage of some kind, dynamic linking would not have any benefits since the dynamically linked code would have to exist in memory in any case so may as well have been statically linked.
To answer the second part of your question, a static library is simply a collection of object files in an archive. The linker will only extract and link the object code necessary to resolve symbols referenced in the executable as a whole. Some smart linkers can discard unused functions from within an object file, but you should not rely on that.
So by linking a static library you are not including all the unused code in the library. You can probably tell that by comparing the size of all your library files with the size of the executable binary - you will probably see that your executable is far smaller than the sum of the sizes of the libraries linked. Also your linker will have an option to create a map file which will tell you exactly what code has been included, and if it has a cross-reference output facility, what code references or is referenced by what.
If you are building your own static libraries, or even your own non-library code, it will pay to ensure good granularity at the object file level. For example if an object file contains two functions, one used and one unused, most linkers will have no choice but to include both, whereas if the functions are defined in separate compilation units (source files), then they will be in separate object files (even when collated into a library) and can be separately linked.
If you really have a embedded system without any operating system, then your hardware has essentially a fixed software, which you can change only by physical means (e.g. a soldering iron, or plugging something, etc...). In that case, that software runs on the "bare iron" and is doing somehow what an OS is providing (it is managing the physical resources and interacts directly with the I/O ports by appropriate machine instruction).
In particular, an embedded system without any OS cannot have any kind of dynamic libraries, because by definition these libraries need to be inside some files (on the embedded processor), and to have files you need an operating system.
The exact definition of what exactly is an operating system is debatable and fuzzy; I believe that providing a file system is one of the roles of most current OSes
Since shared libraries (or static libraries) are libraries sitting inside some files, you cannot have them without an OS. Something which provide files is by definition an operating system.
Perhaps you are using a cross-development chain to develop your embedded software. If you want to get something which runs on the bare metal, your chain has to ultimately give a single binary image which you can flash into a ROM, then solder or plug that ROM -or transfer somehow physically- in your embedded hardware (some tools enable you to flash an entire self contained processor).
I believe you might be confused, and you should read more about operating systems, kernels, the linux kernel, file systems, syscalls, RTOS, linkers & loaders, cross-compilers, microcontrollers, shared libraries, dynamic linkers ....
As Clifford suggested in comments, you could have an embedded system with some file system and some dynamic linker; in my view that would make an embryonic operating system, but it is a debatable matter of definition.
Notice that making a dynamic linker might not be an easy task (you'll need to do relocation); you could either make a generic ELF dynamic loader, or you could restrict the form of the dynamically loaded modules, and perhaps use your specific ld script to generate them.
You already have all the fundamentals you need. Without an operating system, mass storage (disc, filesystem, etc) and mulitple/many different programs that can take advantage of the shared library it doesnt make any sense. You dont save anything and it probably costs you a little more if you were to fake it enough to use a shared library in a fixed bare metal environment.
You mentioned having codesourcery, how do you learn these things? You disassemble your binaries and see what the compiler did. Does it link the entire gcc library because you used one divide? Does it link the entire C library because you used one function (does it even work to try to link a C library function, many have system calls to an operating system which you have to resolve). Start by using a simple divide in a very simple function (needs to be generic)
unsigned int fun ( unsigned int a, unsigned int b )
{
return(a/b);
}
DO NOT call that function with fixed constants and do not call it from the same .c file, the best thing would be to simply add that function as is, and do nothing else with it just have it sit there. You may hit problems even trying to compile it, once you do, disassemble and see what the compiler did with it, see if the entire gcc library was added or just the code for that one function.
You cant trust any old web page or resource as it may not be the same tools you are using and may be out dated, the compiler you are using right now is the one that matters, right now, no other. And the answers are all right there in front of you.
No, they dont use dynamic libraries, the functions needed are linked in as needed. The optimizer may choose to inline some code, but in general the code for each function is in one place and each call to it is a call, it is not like a macro, in general. Again the optimizer may choose otherwise for performance reasons (small enough functions that dont consume too much memory and are small enough that the code required to make a function call is excessive compared to the function itself. Also that function needs to be in the same optimization space, for gcc this is the same .c file, for llvm this could be any code in the project.
I have some examples, cortex-m and others, bare metal. http://github.com/dwelch67 you may find some that may help answer your questions, examine for example that the compiler will implement a public function like the one above AND inline it when used. If you declare the function as static, then the optimizer, if it inlines, doesnt need to implement the function in the binary. if you make a call to a function like that in the same .c file, for example
c = fun(10,5);
there is a good chance that the optimizer if used, will replace that code with
c = 2;
and not perform the divide at all.
This is an iOS question.
I build a static library (a framework in iOS) which is then included in an app. The size of the result binary (500kb) is smaller than the size of the static library (6mb). How does this work? My understanding of static library is that the static library is included in the final binary
Because you are not using all the functions of your library. A static library of archive type .a is a collection of .o object files and only the object files needed in your program are included at link time.
Whenever you statically link an executable, the linker can go ahead and resolve all symbol names (i.e. map them to an address) since all the symbols it will know about you have provided to the linker now (in the form of .o files and .a libraries which are really just a collection of .o files). If there are names that aren't there, you'll get a link error (this is different than dynamic linking where you may be able to load another library at runtime). In your case, you have extra symbols that are unreferenced by the executable. Since these symbols are known to the linker as being unused they are simply removed from the executable output. So your executable will be smaller than the input libraries in this case.