How does g++ link an objective file .o built by gcc?

How does g++ link an objective file .o built by gcc?

[Dingjun Chen]

[-- Attachment #1.1: Type: text/plain, Size: 1740 bytes --]

HI, everyone,

I have a question for you.

I have multiple c++ files .cc (main program is C++) and one c file 'librtd-dm6620.c'. Of course I will use g++ to build the executable. For that 'librtd-dm6620.c' file I still want to build its .o file via gcc because there are some possibly fatal warnings if I use g++ to build this .c file. If this .c file is built with gcc, there is no any warning and it is perfect in compilation.

Finally, I want to build the executable by linking all .o files via g++.  The problem is that the .o file built by gcc is not really linked by g++.  All defined functions in 'librtd-dm6620.c' cannot be found by the g++ linker 'ld'.

I use CMake to build the executable. Could someone tell me how to link an objective file built by gcc into C++ executable? Did I miss some special compiling options for the c file 'librtd-dm6620.c'?

Please see the error information in the file attached for details.

I look forward to your help and hearing from you.

Thanks & Regards,

Dingjun
Dingjun Chen  | Software Developer

[Geotech Airborne Geophysical Surveys]

Geotech Ltd. dba Geotech Airborne | 270 INDUSTRIAL PKY S | AURORA ON CA | L4G 3T9
T: +1 905 841 5004 | Dingjun.Chen@geotechairborne.com<mailto:Dingjun.Chen@geotechairborne.com> | www.geotechairborne.com<www.geotech.ca>

P Please consider the environment before printing this email

This message may contain PRIVILEGED AND PROPRIETARY INFORMATION intended solely for the use of the addressee (s) named above. Any disclosure, distribution, copying, or use of the information by others is strictly prohibited. If you have received this message in error, please advise the sender by immediate reply and delete the original message.

[-- Attachment #2: output.txt --]
[-- Type: text/plain, Size: 5967 bytes --]

Scanning dependencies of target vtem_xyz
[  4%] Building CXX object CMakeFiles/vtem_xyz.dir/src/adcGS.cc.o
[  8%] Building CXX object CMakeFiles/vtem_xyz.dir/src/c_8x16.cc.o
[ 12%] Building CXX object CMakeFiles/vtem_xyz.dir/src/dac6620.cc.o
[ 16%] Building CXX object CMakeFiles/vtem_xyz.dir/src/dongle_interface.cc.o
[ 20%] Building CXX object CMakeFiles/vtem_xyz.dir/src/emstream.cc.o
[ 25%] Building CXX object CMakeFiles/vtem_xyz.dir/src/fmenu.cc.o
[ 29%] Building CXX object CMakeFiles/vtem_xyz.dir/src/frqdom.cc.o
[ 33%] Building CXX object CMakeFiles/vtem_xyz.dir/src/gmenu.cc.o
[ 37%] Building CXX object CMakeFiles/vtem_xyz.dir/src/graph.cc.o
[ 41%] Building CXX object CMakeFiles/vtem_xyz.dir/src/gsc24dsi_interface.cc.o
[ 45%] Building CXX object CMakeFiles/vtem_xyz.dir/src/keybrd.cc.o
[ 50%] Building CXX object CMakeFiles/vtem_xyz.dir/src/mouse.cc.o
[ 54%] Building CXX object CMakeFiles/vtem_xyz.dir/src/processdngl.cc.o
[ 58%] Building CXX object CMakeFiles/vtem_xyz.dir/src/processxyz.cc.o
[ 62%] Building CXX object CMakeFiles/vtem_xyz.dir/src/runproc.cc.o
[ 66%] Building CXX object CMakeFiles/vtem_xyz.dir/src/serialmsg.cc.o
[ 70%] Building CXX object CMakeFiles/vtem_xyz.dir/src/simulant.cc.o
[ 75%] Building CXX object CMakeFiles/vtem_xyz.dir/src/systemid.cc.o
[ 79%] Building CXX object CMakeFiles/vtem_xyz.dir/src/Vtem24.cc.o
[ 83%] Building CXX object CMakeFiles/vtem_xyz.dir/src/_d_aes.cc.o
[ 87%] Building CXX object CMakeFiles/vtem_xyz.dir/src/_d_hexbin.cc.o
[ 91%] Building CXX object CMakeFiles/vtem_xyz.dir/src/_d_serial.cc.o
[ 95%] Building C object CMakeFiles/vtem_xyz.dir/src/librtd-dm6620.c.o
[100%] Linking CXX executable ../bin/vtem_xyz
CMakeFiles/vtem_xyz.dir/src/dac6620.cc.o(.text+0x576): In function `OpenDAC()':
: undefined reference to `OpenBoard6620(DM6620_Board_Descriptor**, int)'
CMakeFiles/vtem_xyz.dir/src/dac6620.cc.o(.text+0x5b1): In function `StartDAC()':
: undefined reference to `SetDACUpdateEnable6620(DM6620_Board_Descriptor*, int, int, int, int)'
CMakeFiles/vtem_xyz.dir/src/dac6620.cc.o(.text+0x5be): In function `StartDAC()':
: undefined reference to `DoneTimer6620(DM6620_Board_Descriptor*)'
CMakeFiles/vtem_xyz.dir/src/dac6620.cc.o(.text+0x5cb): In function `StartDAC()':
: undefined reference to `InitBoard6620(DM6620_Board_Descriptor*)'
CMakeFiles/vtem_xyz.dir/src/dac6620.cc.o(.text+0x5e0): In function `StartDAC()':
: undefined reference to `SelectTimerCounter6620(DM6620_Board_Descriptor*, DM6620HR_TIMER_SEL)'
CMakeFiles/vtem_xyz.dir/src/dac6620.cc.o(.text+0x5fd): In function `StartDAC()':
: undefined reference to `ClockDivisor6620(DM6620_Board_Descriptor*, DM6620HR_CLK, unsigned short)'
CMakeFiles/vtem_xyz.dir/src/dac6620.cc.o(.text+0x61a): In function `StartDAC()':
: undefined reference to `SetDACRange6620(DM6620_Board_Descriptor*, DM6620HR_DAC, DM6620HR_DAC_RANGE)'
CMakeFiles/vtem_xyz.dir/src/dac6620.cc.o(.text+0x637): In function `StartDAC()':
: undefined reference to `SetDACRange6620(DM6620_Board_Descriptor*, DM6620HR_DAC, DM6620HR_DAC_RANGE)'
CMakeFiles/vtem_xyz.dir/src/dac6620.cc.o(.text+0x654): In function `StartDAC()':
: undefined reference to `SetDACUpdate6620(DM6620_Board_Descriptor*, DM6620HR_DAC, DM6620HR_DAC_UPDATE)'
CMakeFiles/vtem_xyz.dir/src/dac6620.cc.o(.text+0x671): In function `StartDAC()':
: undefined reference to `SetDACUpdate6620(DM6620_Board_Descriptor*, DM6620HR_DAC, DM6620HR_DAC_UPDATE)'
CMakeFiles/vtem_xyz.dir/src/dac6620.cc.o(.text+0x6b1): In function `StartDAC()':
: undefined reference to `FillDACFIFO6620(DM6620_Board_Descriptor*, DM6620HR_DAC, unsigned short, unsigned short)'
CMakeFiles/vtem_xyz.dir/src/dac6620.cc.o(.text+0x6f8): In function `StartDAC()':
: undefined reference to `FillDACFIFO6620(DM6620_Board_Descriptor*, DM6620HR_DAC, unsigned short, unsigned short)'
CMakeFiles/vtem_xyz.dir/src/dac6620.cc.o(.text+0x71c): In function `StartDAC()':
: undefined reference to `SetDACCycle6620(DM6620_Board_Descriptor*, DM6620HR_DAC, DM6620HR_DAC_CYCLE)'
CMakeFiles/vtem_xyz.dir/src/dac6620.cc.o(.text+0x739): In function `StartDAC()':
: undefined reference to `SetDACCycle6620(DM6620_Board_Descriptor*, DM6620HR_DAC, DM6620HR_DAC_CYCLE)'
CMakeFiles/vtem_xyz.dir/src/dac6620.cc.o(.text+0x766): In function `StartDAC()':
: undefined reference to `SetDACUpdateEnable6620(DM6620_Board_Descriptor*, int, int, int, int)'
CMakeFiles/vtem_xyz.dir/src/dac6620.cc.o(.text+0x78b): In function `StopDAC()':
: undefined reference to `SetDACCycle6620(DM6620_Board_Descriptor*, DM6620HR_DAC, DM6620HR_DAC_CYCLE)'
CMakeFiles/vtem_xyz.dir/src/dac6620.cc.o(.text+0x7a8): In function `StopDAC()':
: undefined reference to `SetDACCycle6620(DM6620_Board_Descriptor*, DM6620HR_DAC, DM6620HR_DAC_CYCLE)'
CMakeFiles/vtem_xyz.dir/src/dac6620.cc.o(.text+0x7d5): In function `StopDAC()':
: undefined reference to `SetDACUpdateEnable6620(DM6620_Board_Descriptor*, int, int, int, int)'
CMakeFiles/vtem_xyz.dir/src/dac6620.cc.o(.text+0x7fa): In function `StopDAC()':
: undefined reference to `FillDACFIFO6620(DM6620_Board_Descriptor*, DM6620HR_DAC, unsigned short, unsigned short)'
CMakeFiles/vtem_xyz.dir/src/dac6620.cc.o(.text+0x81f): In function `StopDAC()':
: undefined reference to `FillDACFIFO6620(DM6620_Board_Descriptor*, DM6620HR_DAC, unsigned short, unsigned short)'
CMakeFiles/vtem_xyz.dir/src/dac6620.cc.o(.text+0x834): In function `StopDAC()':
: undefined reference to `UpdateDAC6620(DM6620_Board_Descriptor*, DM6620HR_DAC)'
CMakeFiles/vtem_xyz.dir/src/dac6620.cc.o(.text+0x849): In function `StopDAC()':
: undefined reference to `UpdateDAC6620(DM6620_Board_Descriptor*, DM6620HR_DAC)'
CMakeFiles/vtem_xyz.dir/src/dac6620.cc.o(.text+0x85f): In function `CloseDAC()':
: undefined reference to `CloseBoard6620(DM6620_Board_Descriptor*)'
collect2: ld returned 1 exit status
make[2]: *** [CMakeFiles/vtem_xyz.dir/build.make:667: ../bin/vtem_xyz] Error 1
make[1]: *** [CMakeFiles/Makefile2:68: CMakeFiles/vtem_xyz.dir/all] Error 2
make: *** [Makefile:84: all] Error 2

Re: How does g++ link an objective file .o built by gcc?

[Jonathan Wakely]

On Thu, 4 Jan 2024 at 18:48, Dingjun Chen
<Dingjun.Chen@geotechairborne.com> wrote:
>
> HI, everyone,
>
> I have a question for you.
>
> I have multiple c++ files .cc (main program is C++) and one c file 'librtd-dm6620.c'. Of course I will use g++ to build the executable. For that 'librtd-dm6620.c' file I still want to build its .o file via gcc because there are some possibly fatal warnings if I use g++ to build this .c file. If this .c file is built with gcc, there is no any warning and it is perfect in compilation.

Then that means you are trying to compile C code using the C++
compiler. That might work sometimes, for some C code, but will often
not work. C and C++ are different languages.


>
> Finally, I want to build the executable by linking all .o files via g++.  The problem is that the .o file built by gcc is not really linked by g++.  All defined functions in 'librtd-dm6620.c' cannot be found by the g++ linker 'ld'.

That's because the C++ compiler uses "name mangling" when it compiles
functions, so that the symbol names in the .o are different when
compiled as C++.

For example, a function void f() { } will be compiled to a symbol
called "f" when compiled as C, but a symbol called "_Z1fv" when
compiled as C++.

You either need to compile all your C files as C++, so that the symbol
names are all consistent, or you need to tell the C++ compiler not to
mangle the names, like so:

#ifdef __cplusplus
extern "C" {
#endif
void f() { }
#ifdef __cplusplus
}
#endif

When this is compiled by a C++ compiler it will produce a symbol
called "f", just like when compiled by a C compiler.

The simplest answer is probably just to stop trying to compile C files
as C++ code. Either write C++, or write C, don't write C and then
compile as something different.

RE: How does g++ link an objective file .o built by gcc?

[Dingjun Chen]

Thanks indeed to Jonathan! Your idea works well for me. 

Have a great day!

Dingjun 

-----Original Message-----
From: Jonathan Wakely <jwakely.gcc@gmail.com> 
Sent: Thursday, January 4, 2024 1:53 PM
To: Dingjun Chen <Dingjun.Chen@geotechairborne.com>
Cc: gcc-help@gcc.gnu.org
Subject: Re: How does g++ link an objective file .o built by gcc?

External Email Warning: Do not click any links or open any attachments unless you trust the sender and know the content is safe. From Geotech IT.



On Thu, 4 Jan 2024 at 18:48, Dingjun Chen <Dingjun.Chen@geotechairborne.com> wrote:
>
> HI, everyone,
>
> I have a question for you.
>
> I have multiple c++ files .cc (main program is C++) and one c file 'librtd-dm6620.c'. Of course I will use g++ to build the executable. For that 'librtd-dm6620.c' file I still want to build its .o file via gcc because there are some possibly fatal warnings if I use g++ to build this .c file. If this .c file is built with gcc, there is no any warning and it is perfect in compilation.

Then that means you are trying to compile C code using the C++ compiler. That might work sometimes, for some C code, but will often not work. C and C++ are different languages.


>
> Finally, I want to build the executable by linking all .o files via g++.  The problem is that the .o file built by gcc is not really linked by g++.  All defined functions in 'librtd-dm6620.c' cannot be found by the g++ linker 'ld'.

That's because the C++ compiler uses "name mangling" when it compiles functions, so that the symbol names in the .o are different when compiled as C++.

For example, a function void f() { } will be compiled to a symbol called "f" when compiled as C, but a symbol called "_Z1fv" when compiled as C++.

You either need to compile all your C files as C++, so that the symbol names are all consistent, or you need to tell the C++ compiler not to mangle the names, like so:

#ifdef __cplusplus
extern "C" {
#endif
void f() { }
#ifdef __cplusplus
}
#endif

When this is compiled by a C++ compiler it will produce a symbol called "f", just like when compiled by a C compiler.

The simplest answer is probably just to stop trying to compile C files as C++ code. Either write C++, or write C, don't write C and then compile as something different.