Convert Object File to Another Architecture

Convert object file to another architecture

Um, no, it looks to me like a waste of time. Wi-Fi driver is complex, and you say this one troublesome object file is 'large'. Lots of pain to translate, and chance of successful debug slim to none. Also, any parameter passing between this one object file and the rest of the system would not translate directly between x86 and ARM.

Why can't object (.obj) files be moved across platforms?

The C language is platform independent.

The files generated by the compiler, the object and executable files, are platform dependent. This is due to the fact the ultimate goal of a compiler is to generate an executable file for the target architecture only, not for every known architecture.

Java class files are platform independent because Sun was the only designer of Java, it actually made all the rules (from bytecode to file format and VM behavior) and everyone else had to adapt.

This didn't happen with native binary formats, every OS made its format, compiler made its object format and every CPU has its own ISA.

How do I link object files in C? Fails with Undefined symbols for architecture x86_64

I assume you are using gcc, to simply link object files do:

$ gcc -o output file1.o file2.o

To get the object-files simply compile using

$ gcc -c file1.c

this yields file1.o and so on.

If you want to link your files to an executable do

$ gcc -o output file1.c file2.c

How to properly make a object file from header file (using an I2C board with a debian linux machine)

You don't make any object file from a header file. On Linux object files (and executables) are ELF files. Use file(1) (or objdump(1) ...) to check.

Instead, a header file should be included (by #include preprocessor directive) in some *.cc file (technically a translation unit).

^{(You could precompile headers, but this is only useful to improve compilation time, which it does not always, and is an advanced and GCC specific usage; see this)}

You do compile a C++ source file (some *.cc file) into an object file suffixed .o (or a C source file *.c compiled into an object file suffixed .o)

Read more about the preprocessor, and do spend several days reading about C or C++ (which are different programming languages). Read also more about compiling and linking.

I recommend to compile your C++ code with g++ -Wall -Wextra -g to get all warnings (with -Wall -Wextra ) and debug information (with -g).

A minimal compilation command to compile some yourfile.cc in C++ into an object file yourfile.o should probably be

g++ -c -Wall -Wextra -g yourfile.cc

^{(you could remove -Wall -Wextra -g but I strongly recommend to keep them)}

You may need to add other arguments to g++. They order matters a lot. Read the chapter about Invoking GCC

Notice that yourfile.cc contains very likely some (and often several) #include directives (usually near its start)

You very rarely need the -x c++ option to g++ (or -x c with gcc). I used it only once in my lifetime. In your case it surely is a mistake.

Very often, you use some build automation tool like GNU make. So you just use make to compile (but you need to write a Makefile - where tabs are significant)

Notice that some libraries can be header only (but this is not very usual), then you don't build any shared or static ELF libraries from them, but you just include headers in your own C or C++ code.

addenda

Regarding your http://dlnware.com/sites/dlnware.com/files/downloads/linux_setup.2.0.0.zip package (which indeed is poorly documented), you should look at the several examples given in the linux_setup/examples/ directory. Such code all have a #include "../common/dln_generic.h" (for instance, 4^th line of examples/leds_gui/main.cpp) which itself have other includes. All the examples are Qt applications and provide a *.pro file for qmake (which itself generates a Makefile for make from that .pro file). And passing -x c++ to g++ is rightly not mentioned at all.

How to change architectures in static libraries?

There isn't any way to convert the architecture of an existing library. You'll need to go back to the original source and recompile it with the new architecture added.

Some questions regarding compilers and assemblers

Question 1: yes, an assembler (as, gas, nasm, masm) compiles assembly instructions to object code. In case of high-level languages (H) the compiler compiles H to either another language (for example GHC, the Glorious Haskell Compiler can produce C, but it can also produce C--, and there was an attempt(?) to produce Java), or into object code through intermediate steps (or languages C-- or Core).

Intermediate code can be generated for many reasons:
1. portability for example .class files from java, p-code for Pascal
2. to facilitate code optimisations

Question 2: .class files can be generated by a java compiler, but Scala also generates .class files, and AspectJ (the aspect oriented flavour) also produces .class files. .class files are not object files in the sense that they need the Java Virtual Machine (and the unix linker ld won't link .class files against .o files). The original JVM is an interpreter for .class files, but you can compile java on-the-fly too.

Question 3: Turbo C++ .obj files (compiled on 64 bit intel) would not be happy on a Z80 machine unless the compiler has the option of cross-compiling for another architecture, so in the case of Turbo C++ the purpose of the object file is not portability across platforms.

---

Related Topics