public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/56066] New: g++ generates strong symbols conflicting with C99 extern inline code on Windows
@ 2013-01-21 15:05 solomon.gibbs.lists at gmail dot com
  2013-01-24 19:42 ` [Bug c++/56066] " solomon.gibbs.lists at gmail dot com
                   ` (4 more replies)
  0 siblings, 5 replies; 6+ messages in thread
From: solomon.gibbs.lists at gmail dot com @ 2013-01-21 15:05 UTC (permalink / raw)
  To: gcc-bugs


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


^ permalink raw reply	[flat|nested] 6+ messages in thread
end of thread, other threads:[~2021-06-20  9:23 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-01-21 15:05 [Bug c++/56066] New: g++ generates strong symbols conflicting with C99 extern inline code on Windows solomon.gibbs.lists at gmail dot com
2013-01-24 19:42 ` [Bug c++/56066] " solomon.gibbs.lists at gmail dot com
2013-11-26 18:27 ` ktietz at gcc dot gnu.org
2013-12-27 14:02 ` ktietz at gcc dot gnu.org
2013-12-31  5:02 ` solomon.gibbs.lists at gmail dot com
2021-06-20  9:23 ` [Bug target/56066] " pinskia at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).