User forums > Using Code::Blocks

C naming convention and underscores

<< < (2/3) > >>

ikolev:

--- Quote from: Game_Ender on March 03, 2006, 01:15:54 am ---I think he wants those to be displayed more prominently.  I think there should be a notice right below the RC2 message on the front page that user should try the nightly builds if they have problems.
--- End quote ---

Exactly. I understand that the nightly builds are probably less stable and change a lot, but RC2 simply doesn't show the state of the project. And I guess most people don't like to try the "bleeding edge" expecting that it's much less stable, and don't bother downloading nightly builds. But I guess it's a matter of policy when the authors will decide to announce "a new and much improved build". BTW, calling these builds "release candidates" is not a good idea, since one expects from RC's to represent the final state of the project and only contain bug-fixes from there on.


--- Quote from: Game_Ender on March 03, 2006, 07:42:26 am ---The reason you can just include the std C headers and not have to worry about this is because they already have all the proper defines setup to include the "extern C" if you are using a C++ compiler.
--- End quote ---

Exactly. Naturally, I had examined MMSystem.h and noticed that it includes an extern "C" declaration.


--- Quote from: Game_Ender on March 03, 2006, 01:15:54 am ---About the library.  Both C and C++ compilers do name mangling, although the C method is standard, the compiler just puts a "_" in front of the name which is why you set "_timeGetTime()" in the binary.  Can you set the compiler to show the full command line and then post the results.
--- End quote ---

The problem turned out to be entirely different. First I discovered that the function name was actually the same in the object file that uses timeGetTime and in libwinmm.a - it was "_timeGetTime@0". I should have checked the .o file, but since the GNU linker message was about 'timeGetTime@0' (without a leading _), I decided that this is the exact name of the function as listed in the .o file. It turns out that the linker tries to "beatify" the name a bit, which confused me.
Then I started comparing the command lines issued by C::B and Dev-Cpp. One worked while the other didn't. I couldn't see any important differences. I started converging the two lines step by step and testing them. Finally I found out that the order of listing the object and library files in the command line is important - the linker searches for references only in the following objects on the command line. At this point I realized why in the build options of the C::B IDE you can select whether the target options are to be appended or prepended to the project options. Setting the proper order of command line generation fixed the problem.

So I guess these are just typical experience lessons from using a new compiler/linker... first the misleading error message, then the discovery about importance of order in the command line (I'm sure the MS linker doesn't require any order). I guess the explanation about this "append/prepend" option should be included in a future detailed documentation, for people without GNU C++ experience.
(BTW, I changed the topic to make it a bit more relevant.)

Game_Ender:
I have a releated problem.  I am creating a C++ library with G++, that has needs to have C linkage so it can be loaded by another program.  I thought the way to do this was to create some functions that use your classes, then the wrap the declartions for those functions in extern "C".  After you have done that, compile and linked the shared library, and you will have a shared library with the C symbols properly exported.

I created a very simple test that has two library both which should export the function "add", one in C, and the other in C++.  Then I have two test targets which create a C program.  One tries to link with the C library the other with the C++.  The C++ one fails to link.  Here is the a zip file of the project.

--- Code: ----------------- Build: CppLib in C2C++Lib ---------------
g++  -Iinclude -I/usr/include  -c src/adder.cpp -o .objs/src/adder.o
g++  -Iinclude -I/usr/include  -c src/cinterface.cpp -o .objs/src/cinterface.o
g++ -shared -L/usr/lib  .objs/src/adder.o .objs/src/cinterface.o   -o libcpplib.so 

-------------- Build: CLib in C2C++Lib ---------------
gcc  -Iinclude -I/usr/include  -c src/cadd.c -o .objs/src/cadd.o
g++ -shared -L/usr/lib  .objs/src/cadd.o   -o libclib.so 

-------------- Build: testC in C2C++Lib ---------------
gcc  -Iinclude -I/usr/include  -c src/test.c -o .objs/src/test.o
g++ -L. -L/usr/lib  -o testc .objs/src/test.o    -lclib
Process terminated with status 0 (0 minutes, 0 seconds)
0 errors, 0 warnings
 
-------------- Build: testCpp in C2C++Lib ---------------
g++ -L. -L/usr/lib  -o testcpp .objs/src/test.o    -lcpplib
.objs/src/test.o: In function `main':
test.c:(.text+0x55): undefined reference to `add'
collect2: ld returned 1 exit status
Process terminated with status 1 (0 minutes, 0 seconds)
0 errors, 0 warnings

--- End code ---

I am using Rev 2133.  I think I have to export the symbols in another way but I am unsure.

mandrav:
I haven't tried your project, but something seems wrong:


--- Code: ----------------- Build: testCpp in C2C++Lib ---------------
g++ -L. -L/usr/lib  -o testcpp .objs/src/test.o    -lcpplib
.objs/src/test.o: In function `main':

--- End code ---

I see no compiling here. Just linking.
This leads me to believe the object directory for this target is not unique and so it tries to link the object file already created from another of your targets.

Game_Ender:
I tried separating the obj directories for the two test programs, didn't help.  I expected this, because at the start I only had the one program that tried to link in the C++ library.   I added the C version for testing purposes.  Thanks for the tip though.

mandrav:
I found your problem.
Your test file is named "test.c". This makes gcc compile it as a C file, not C++, so the linking is tried using the C name mangling, even when compiling the C++ version of the test program...

To fix this, add -xc++ in the testCpp target other compiler options. This will force all files built under this target, to be built as C++ no matter what gcc thinks ;).

Navigation

[0] Message Index

[#] Next page

[*] Previous page