Re: What is wrong in this code?

[Angelo Graziosi <graziosi.angelo@gmail.com>]

Just for completeness…

If, on MAC OSX, I redefine the PATH so that the MacPorts installation is completely excluded, the g++,

$ /usr/bin/g++ -v
Using built-in specs.
Target: i686-apple-darwin11
Configured with: /private/var/tmp/llvmgcc42/llvmgcc42-2336.11~67/src/configure --disable-checking --enable-werror --prefix=/Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2 --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-prefix=llvm- --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin11 --enable-llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2336.11~67/dst-llvmCore/Developer/usr/local --program-prefix=i686-apple-darwin11- --host=x86_64-apple-darwin11 --target=i686-apple-darwin11 --with-gxx-include-dir=/usr/include/c++/4.2.1
Thread model: posix
gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)

gives the same (linker) errors…

Ciao,
 Angelo.

Il giorno 10/nov/2012, alle ore 04:25, Michael Witten ha scritto:

> On Fri, 9 Nov 2012 17:55:44 -0800, Ian Lance Taylor wrote:
> 
>> On Fri, Nov 9, 2012 at 12:34 PM, Angelo Graziosi wrote:
>> 
>>> $ cat foo01.cc
>>> #include "foo.hh"
>>> 
>>> MYCLASS_INSTANTIATE_TYPES
>>> 
>>> $ cat foo02.cc
>>> #include "foo.hh"
>>> 
>>> MYCLASS_INSTANTIATE_TYPES
>>> 
>>> $ cat foo.hh
>>> 
>>> #define MYCLASS_INSTANTIATE(g) g(int)
>>> 
>>> #define MYCLASS_INSTANTIATE_BASE(type) \
>>>    template class MyClassBase<type>;
>>> 
>>> #define MYCLASS_INSTANTIATE_TYPES \
>>>  MYCLASS_INSTANTIATE(MYCLASS_INSTANTIATE_BASE)
>>> 
>>> Now what happens is this:
>>> 
>>> Building on *** MAC OSX *** with gcc45, gcc46, gcc47 installed by means of MacPorts, fails as
>>> 
>>> $ g++ foomain.o foo01.o foo02.o -o foo.out
>>> duplicate symbol MyClassBase<int>::ClassWrapper::ClassWrapper() in:
>>>    foo01.o
>>>    foo02.o
>>> duplicate symbol MyClassBase<int>::ClassWrapper::ClassWrapper() in:
>>>    foo01.o
>>>    foo02.o
>>> ld: 2 duplicate symbols for architecture x86_64
>>> collect2: error: ld returned 1 exit status
>>> 
>>> instead it builds (on MAC OSX) using clang++,
>> 
>> This question is not appropriate for the mailing list gcc@gcc.gnu.org.
>> It would be appropriate for gcc-help@gcc.gnu.org.  Please take any
>> followups to gcc-help.  Thanks.
>> 
>> Instantiating a template creates all the instantiations in that
>> compilation unit.  There is no reason to instantiate a template in
>> more than one compilation unit.  The implementation that GCC uses does
>> not permit you to do that.  I don't know what LLVM does.
> 
> According to C++11.14.7, paragraph 5:
> 
>  For a given template and a given set of template-arguments,
> 
>    -- an explicit instantiation definition shall appear at
>       most once in a program,
>  ...
>  An implementation is not required to diagnose a violation of this rule.
> 
> So, it's not allowed for *any* implementation, though an implementation
> need not diagnose it.
> 
> However, Ian, you're missing the most interesting bit from Angelo's email,
> namely that a GCC toolchain doesn't always have a problem with multiple
> instantiations:
> 
>>> It also builds on Cygwin with gcc-4.5.3 and gcc-4.8 snapshot.
>>> 
>>> It builds on GNU/Linux (K)Ubuntu with gcc-4.6.3
> 
> Indeed, his code compiles without error on my x86/Linux machine, using
> g++ 4.7.2 with the options `-std=c++03 -pedantic -Wall -Wextra -Werror'.
> There wasn't one peep from my toolchain.
> 
> Anyway, I would have imagined that this error would only be caught by
> the linker, and that is precisely what happens according to Angelo:
> 
>>> ld: 2 duplicate symbols for architecture x86_64
> 
> Yet, clang++ on the same system has no trouble:
> 
>>> instead it builds (on MAC OSX) using clang++,
> 
> How does that make sense? Is a different linker being used with the
> GCC toolchain? If so, which one? GNU ld doesn't support Mach-O, and
> even if it did, GNU ld doesn't appear to mind the error on at least
> a few other systems.
> 
> Some insight on this aspect would be nice.
> 
> Sincerely,
> Michael Witten