[Bug c++/56066] New: g++ generates strong symbols conflicting with C99 extern inline code on Windows

solomon.gibbs.lists at gmail dot com gcc-bugzilla@gcc.gnu.org
Mon Jan 21 15:05:00 GMT 2013


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56066

             Bug #: 56066
           Summary: g++ generates strong symbols conflicting with C99
                    extern inline code on Windows
    Classification: Unclassified
           Product: gcc
           Version: 4.7.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: solomon.gibbs.lists@gmail.com


Created attachment 29236
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29236
Header file, C99 and C++ file that create conflict

When a C99 translation unit containing extern inline functions is linked with a
C++ translation unit using those same inlines, g++ generates an additional
symbol for the inline function in the C++ TU. Linking causes a multiple
definitions error.

I am informed that this is a likely a problem with PE/COFF and that under ELF,
the g++ generated symbols would be marked weak and eliminated at link time. 

For example, when buffer.h as shown below is included by C99 and C++ TUs, the
error occurs. (Complete files are attached)

// buffer.h
inline bool has_remaining(void* obj) {
...
}

// buffer.c
extern inline bool has_remaining(void* obj);

// app.cpp
int main(...) {
   has_remaining("okay");
   ...
}

// compile
$ gcc -std=gnu99 -o buffer.o -c --save-temps buffer.c
$ g++ -std=gnu++11 -o app.o -c --save-temps app.cpp
$ g++ -Wl,--subsystem,console -o app.exe app.o buffer.o
buffer.o:buffer.c:(.text+0x0): multiple definition of `has_remaining'
app.o:app.cpp:(.text$has_remaining[_has_remaining]+0x0): first defined here
collect2.exe: error: ld returned 1 exit status


$ gcc -v
Using built-in specs.
COLLECT_GCC=C:\opt\MinGW\bin\gcc.exe
COLLECT_LTO_WRAPPER=c:/opt/mingw/bin/../libexec/gcc/mingw32/4.7.2/lto-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.7.2/configure
--enable-languages=c,c++,ada,fortran,objc,obj-c++ --disable-sjlj-exceptions
--with-dwarf2 --enable-shared --enable-libgomp --disable-win32-registry
--enable-libstdcxx-debug --disable-build-poststage1-with-cxx
--enable-version-specific-runtime-libs --build=mingw32 --prefix=/mingw
Thread model: win32
gcc version 4.7.2 (GCC)


$ g++ -v
Using built-in specs.
COLLECT_GCC=C:\opt\MinGW\bin\g++.exe
COLLECT_LTO_WRAPPER=c:/opt/mingw/bin/../libexec/gcc/mingw32/4.7.2/lto-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.7.2/configure
--enable-languages=c,c++,ada,fortran,objc,obj-c++ --disable-sjlj-exceptions
--with-dwarf2 --enable-shared --enable-libgomp --disable-win32-registry
--enable-libstdcxx-debug --disable-build-poststage1-with-cxx
--enable-version-specific-runtime-libs --build=mingw32 --prefix=/mingw
Thread model: win32
gcc version 4.7.2 (GCC)


$ ld -v
GNU ld (GNU Binutils) 2.22



More information about the Gcc-bugs mailing list