What is wrong in this code?
Angelo Graziosi
graziosi.angelo@gmail.com
Sat Nov 10 08:52:00 GMT 2012
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
More information about the Gcc-help
mailing list