Hello,
I'm trying to compile a C app as C++, but it doesn't run. I looked at the .s files, and one difference with the C++ compilation is the line:
IMPORT ||Lib$$Request$$cpplib|| [CODE,WEAK]
Maybe this is the problem (or, one of the problems.)
Is there a way of preventing the compiler from including this library if I compile with the --cpp option?
Why are you compiling C source code as C++ ?
Obviously, if the code is compiled as C++ then corresponding library will be included in the project.
It's possible to want to use references, classes, namespaces etc without wanting to use any C++ library functionality.
Some compilers/linkers manages to include quite a lot of C++ code even if the program doesn't really make use of STL, streams etc.
As Per hypothesized earlier, we want to use some specific language features without pulling in the standard library. To be precise, we'd like to use reference arguments for a particular task, which wouldn't need the cpplib library to be included.
The ARM c++ compiler does not bring in libraries that are not used. They way to prevent it from including the library is by not referencing anything in the library.
in itself does not add anything from the library. Removing it from the .s file would have shown you this.
I can create "Fully Functional" C++ application that are less than 250 bytes in size (yes, they only call main, but they actually do it). Taking a working C app and using the --cpp option will generate identical code. Exactly identical image files.
namespaces add zero code and References only add what you think they should add.
void func(uint32_t *p) { *p *= 4; } void func(uint32_t &p) { p *= 3; }
The reference case and pointer case both generate EXACTLY the same code.
You REALLY needed to not modify the original C app before trying to compile it in C++. Go back to the original and add the --cpp option. When this generates EXACTLY the same code as the C compiler did, you are ready to start adding your C++ stuff. Your issue is in the code that you added to your working code and not something to do with C++ or C++ libraries.
After getting the C EXACTLY the same in C++, as you add new code (don't make "too many" changes at once), it should be much easier to identify what you are doing that is causing the real problem.
We're taking a existing C project, adding the --cpp option, and compiling it. It produces a different binary file. Here are the first bytes of each binary, courtesy of linux "hexdump". The differences begin at line 0000050.
$ hexdump -v binary_image/C/ER_IROM1 | head 0000000 3f88 1000 033d 0001 0341 0001 0343 0001 0000010 0345 0001 0347 0001 0349 0001 0000 0000 0000020 0000 0000 0000 0000 0000 0000 034b 0001 0000030 034d 0001 0000 0000 034f 0001 0351 0001 0000040 0353 0001 0353 0001 0353 0001 0353 0001 0000050 0353 0001 1333 0001 133d 0001 1347 0001 0000060 1351 0001 0353 0001 0353 0001 0933 0001 0000070 093f 0001 0353 0001 0353 0001 0353 0001 0000080 0353 0001 0353 0001 0353 0001 0353 0001 0000090 0353 0001 0353 0001 0353 0001 0353 0001 $ hexdump -v binary_image/Cpp/ER_IROM1 | head 0000000 3f88 1000 033d 0001 0341 0001 0343 0001 0000010 0345 0001 0347 0001 0349 0001 0000 0000 0000020 0000 0000 0000 0000 0000 0000 034b 0001 0000030 034d 0001 0000 0000 034f 0001 0351 0001 0000040 0353 0001 0353 0001 0353 0001 0353 0001 0000050 0353 0001 0353 0001 0353 0001 0353 0001 0000060 0353 0001 0353 0001 0353 0001 0353 0001 0000070 0353 0001 0353 0001 0353 0001 0353 0001 0000080 0353 0001 0353 0001 0353 0001 0353 0001 0000090 0353 0001 0353 0001 0353 0001 0353 0001
These binaries are built with 2 different startup files. That was something that you needed to avoid.