Hi - Summary ======= Given only these two files: (1) an existing Linux32 executable file in ELF format (but no *.c file, and no *.o file), and (2) a corresponding C header file (*.h) declaring several 'extern' functions defined in the above ELF file... Question -------- Is it possible to use gcc (or some similar tool) to produce a shared/dynamic library (*.so file) [or alternatively, a static library (*.a file)]... ...using **only** the original ELF executable and the C header file (*.h) - ie, with no C source file (*.c) and no object file (*.o) available? Motivation ========== I need to do this so I can call the functions defined in an old existing executable file in ELF format (actually, just the ones declared in the C header file supplied with the ELF file) from some other, new C "client" program(s) which I'm writing. Further info ============ The Linux command 'file' returns the following info for the ELF file: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.2.5, stripped This existing executable in ELF format is very small (under 200k), and has just a handful of utility functions declared in its C header file (under 30), which are mainly used to serialize and deserialize structs containing int's, float's, char's, strings (and arrays and lists recursively built therefrom) in order to efficiently send them between the existing ELF executable and other, new C "client" programs via socket connections. The documentation for the ELF executable does recommend calling it for this purpose from other "client" programs written in C (this is why it provides the C header file for the existing ELF, as well as a *.lib to go with the *.dll file for use on Win32), but I have no idea how (or if!) it is possible to link an existing executable ELF file, even given a C header file declaring a subset of the interesting (API) functions defined in the ELF. Some experiments ================ Just taking a wild guess, I tried the following three approaches, where: - 'utilprog' is the given executable (the existing Linux32 ELF file, with no filename extension), and - 'my_client.c' is my new C source "client" program, which includes - the existing C header file for the existing ELF (#include "utilprog.h") Approach (1) ------------ - Use 'ld -r' on the ELF 'utilprog' to a produce a relocatable object file 'utilprog.o' - Use 'gcc -shared' on 'utilprog.o' to produce a dynamic/shared library 'libutilprog.so'; - Try to use gcc to compile 'my_client' & dynmically link ... FAILS! ------------ http://stackoverflow.com/questions/2980102/combine-two-gcc-compiled-o-object-files-into-a-third-o-file http://www.adp-gmbh.ch/cpp/gcc/create_lib.html Linux32> ld -r utilprog -o utilprog.o Linux32> gcc -shared -Wl,-soname,libutilprog.so.1 -o libutilprog.so.1.0.1 utilprog.o Linux32> ln -sf libutilprog.so.1.0.1 libutilprog.so Linux32> gcc my_client.c -L. -lutilprog -o my_client ---------------------------------------------------- The last step gives three errors: "multiple definition of `no symbol' ... size of symbol `' changed ..." Approach (2) ------------ - Use 'ld -r' on ELF file 'utilprog' to a produce a relocatable object file 'utilprog.o' - Use 'ar rcs' on 'utilprog.o' to produce a static library 'libutilprog.a' - Try to use gcc to compile & statically link ... FAILS! ------------ Linux32> ld -r utilprog -o utilprog.o Linux32> ar rcs libutilprog.a utilprog.o Linux32> gcc -static my_client.c -L. -lutilprog -o my_client ------------------------------------------- The last step gives: "undefined reference" for each function called in my_client.c that was declared 'extern' in the existing C header 'utilprog.h' (and defined in the existing executable ELF 'utilprog') Approach (3) ------------ Attempt to compile *without* linking (on the crazy assumption that the header file might somehow "link" to the executable if they're both named the same :-) ------------ Linux32> gcc my_client.c -o my_client.o --------------------------------------------- This doesn't work - last step gives three errors: "multiple definition of `no symbol' ... size of symbol `' changed ..." (same as Approach (1) above) Remarks ======= As you can see I'm a total novice with gcc. Normally I would think it might make sense for it to be impossible to access functions in an existing executable ELF file - but in this case, given the C header file with 'extern' declarations for a subset of functions defined in the ELF file (which is meant to provide a kind of public interface or API for the ELF file), it seems that maybe there is some way to convert the existing executable ELF file to a library and link it to other "client" programs - particularly when the documentation for the existing executable ELF file recommends doing precisely this. Thanks for any suggestions!
