I have a static library, where one of the objects defines a symbol:
nm mylib.a
...
00007340 t _a_local_symbol
...
I need to access the function from my C code. Obviously, I don't have the source code for the library, so I can work only with the archive file that I have at hand.
This is further restricted by iOS linker.
A bit more context. The library is Objective-C++, the function in question is pure C. I don't have original headers, but I've got the function signature restored.
objcopy has a flag to do what you want:
--globalize-symbol <name> Force symbol <name> to be marked as a global
Not sure whether objcopy works on iOS object files though.
Related
Let's say I want to call a C function: printf, getpid, socketpair or any other standard C function from my code in Assembly language. I know how to do that in terms of implementation. However, I'll also have to know where one of those functions defined -- in what Linux file, so that I can pass the name of that of that file to the linker. I think it should be a "so" file. How would I find out in what file it's defined?
Note that my question is general and the functions I've mentioned above are just an example. How would I know in what Linux library any arbitrary C function defined?
These (printf, getpid, socketpair) are all part of the standard C library. That's the library that gets automatically linked to every C program.
I think the easiest way to solve your problem would be to link it with gcc, which will call the linker and link the appropriate version of the standard C library in.
If you want to proceed your way:
echo 'int main(){ }' |gcc -x c - && ldd ./a.out |grep libc
should give you the so file. In my case it's:
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fc3a2b46000)
There's no generic solution for function x as far as I know.
You'd have to google to map a function to a library. If the library uses a library specific prefix instead of bare names (like the standard C library unfortunately does in most cases), googling it should be fairly unambiguous. (After that, you'd need to find where the library's SO file is on your system.)
If it's a standard C library function, libc.so is probably correct.
If it's another library, that library's documentation should tell you. Eg. the manpage for pthread_create says
Compile and link with -pthread
and you then need to look at the GCC documentation to see what it does with that option (eg, -lpthread plus some other stuff, so you want libpthread.so).
With third-party libraries, the onus is entirely on the library developer/distributor to tell you where to find the symbols listed in their API.
Worst case you can just find all .so files under /usr, /lib, /opt or wherever else you have libraries installed, and run nm -D on them. You're looking for entries of type t or T.
Note we're assuming that you only want shared objects (dynamic libraries) - if you're talking about arbitrary third-party libraries, they could equally ship static (.a) archives.
I'm trying to use a c library in RubyMotion, and in order to call out to functions in the library I need to generate a bridgesupport file. RubyMotion is requesting the generation of this file, but I can see that not a single variadic function from the library appears in the bridgesupport file. I've tried walking through the source of gen_bridge_metadata, but in the end it calls out to a parser in a shared object lib so I can't get much further than that. All I can see is that it's not declaring an AFunctionDecl for that function.
Are variadic functions just not supported full stop, or is there some sort of config that I need to apply somewhere?
So this appears to be caused by not having all the .h and .a files for the library and it's dependencies together in the same directories. Eg. I had:
/vendor/lib1
/vendor/lib2
/vendor/lib3
when I should have had
/vendor/lib3 (containing all of lib1 + lib2 as well)
We try to build tests in java from a fortran library and we would like to check COMMON variables. Is there a way to do it ?
If the symbol for it shows up in your shared library (use nm or objdump to look for it), then you can likely request its address using NativeLibrary.getGlobalVariableAddress(), then extract its value using the appropriate Pointer.getXXX() method.
In a static library project for iOS 6, some functions in a .c file is referenced by others, and therefore are considered global symbols, but should not be exposed to the user of this library.
How can I strip these function names out? Also, how can I hide those obj file names as well so that nobody could see the .o names in nm output?
I have tried to enable/set:
Deployment Postprocessing
Strip Debug Symbols During Copy
Strip Linked Product
Strip Stype: either 'Non-Global Symbols' or 'Debugging symbols'
Use Separate Strip
EDIT:
I see that there is another Build Setting item 'Additional Strip Flags'.
By adding in it a flag -R /path/to/symbol_list_file, strip command would remove symbols indicated in the file, or -s /path/to/exported_symbol_list_file -u to indicate interfaces and leaving undefined symbols at the same time.
No, you can't. A static library is simply a collection of object files and the object files within the static library have no special privileges over those using the static library.
You can obviously strip the final binary.
If you must hide symbols then they need to be static, which forces you to use fewer implementations files to allow the symbol to be shared, which is inconvenient.
I need to patch a method in Classes.pas
(TReader.ReadString - I want to force it to use a specified codepage, not the system default).
If I copy Classes.pas into my project,I will end up having to rebuild the entire VCL. Is there any (easy) way to patch a method at runtime?
Modifying the implementation side of Classes.pas will not require recompiling everything. Delphi figures out if a unit needs to be recompiled by an algorithm that looks roughly like this:
If DCU found:
Is DCU format out of date (old version of compiler)? If so, need source to recompile or compile-time error.
Is the source on the path? If so, if it's newer than the DCU, recompile
For each used unit:
Repeat analysis when loading
For each used symbol ("import": type, variable, routine, initialized constant etc.) from that unit:
Is symbol version of import different to symbol found in used unit? If so, recompile needed.
If DCU is not found, source will need to be found and compiled, otherwise compile-time error
The important concept is that of symbol version. When saving a DCU, Delphi calculates a hash based on the interface declaration of the symbol and associates it with the symbol. Other units that use the symbol also store the symbol version. In this way, link-time conflicts caused by stale symbols are avoided, unlike most C linkers.
The upshot of this is that you should be able to add Classes.pas to your project and modify its implementation section almost to your heart's content, and still be able to statically link with the rest of the RTL and VCL and third-party libraries, even those provided in object format only.
Things to be careful of:
Inlined routines; the body of inlined routines are part of the symbol version
Generics; the implementation side of generic types and methods are part of the respective symbol versions
I found VCLFixPack:
https://www.idefixpack.de/blog/bugfix-units/vclfixpack-10/
I used the techniques from this to replace the method I wanted to patch at runtime.