duplicate symbol typeinfo under MacOS #734

hivon · 2020-03-24T15:07:27Z

This problem looks a bit like #677.
Under MacOS 10.14.6, with GNU CC 8.3.0 (as well as 9.2.0),
the release 1.0.0-rc.2 (as well as the git version of March 24),
crashes at linking with the error message

[100%] Linking CXX executable gdl
duplicate symbol typeinfo name for Data_<SpDComplex> in:
    CMakeFiles/gdl.dir/datatypes.cpp.o
    CMakeFiles/gdl.dir/basic_op.cpp.o
duplicate symbol typeinfo for Data_<SpDComplex> in:
    CMakeFiles/gdl.dir/datatypes.cpp.o
    CMakeFiles/gdl.dir/basic_op.cpp.o
duplicate symbol typeinfo name for Data_<SpDUInt> in:
    CMakeFiles/gdl.dir/datatypes.cpp.o
    CMakeFiles/gdl.dir/basic_op.cpp.o
...
duplicate symbol typeinfo for Data_<SpDLong64> in:
    CMakeFiles/gdl.dir/datatypes.cpp.o
    CMakeFiles/gdl.dir/ofmt.cpp.o
ld: 252 duplicate symbols for architecture x86_64

Any way out ?

The text was updated successfully, but these errors were encountered:

alaingdl · 2020-03-25T00:22:02Z

Unfortunately unable to replicate because the Mac I use with 10.14 is crashed at the observatory, physical access denied because of Covid :((

I have an issue on OSX 10.12, to be solve (push) in "saverestore.cpp" (string issue)
Apple LLVM version 8.0.0 (clang-800.0.42.1)
no message when compiling on Debian 10 with Clang-7
clang version 7.0.1-8 (tags/RELEASE_701/final)
CC=clang CXX=clang++ cmake .. -DPYTHON=OFF

GillesDuvert · 2020-03-25T11:12:05Z

can you confirm that the file instantiate_templates.cpp is as in
144ab6e#commitcomment-37668301
?

alaingdl · 2020-03-25T11:19:04Z

The machine with OSX 10.14.4 was just restarted, compilation with Clang 10 is OK. I will test now GCC.

[[email protected]:]$ CC=clang CXX=clang++ cmake .. -DPYTHON=OFF -DOPENMP=OFF  \
-DGEOTIFF=OFF  -DSHAPELIB=OFF

[...]

[[email protected]:]$ clang --version
Apple LLVM version 10.0.0 (clang-1000.10.44.4)
Target: x86_64-apple-darwin18.5.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

[[email protected]:]$ sw_vers 
ProductName:	Mac OS X
ProductVersion:	10.14.4
BuildVersion:	18E226

hivon · 2020-03-25T12:10:37Z

Hi @GillesDuvert,
I tried after adding the #ifdef lines in instantiate_templates.hpp
(not .cpp which does not exist),
but it makes no difference on the linking, as already noted by @opoplawski.

alaingdl · 2020-03-25T14:08:50Z

Replicated on OSX 10.14.4 with GCC 8, lot of messages (similar)

[[email protected]:]$  CC=gcc-8 CXX=g++-8 cmake .. -DPYTHON=OFF \
 -DOPENMP=OFF  -DGEOTIFF=OFF  -DSHAPELIB=OFF \
 -DWXWIDGETS=OFF -DHDF=OFF -DPSLIB=OFF -DEDITLINE=off -DMAGICK=off

unclear for me why so much dependencies should be switch OFF for GCC and not for Clang

GillesDuvert · 2020-03-25T14:34:33Z

This comes probably from the #include "datatypes.hpp" //for friend declaration
that are still present in:

assocdata.cpp
basic_op.cpp
basic_op_add.cpp
basic_op_div.cpp
basic_op_mult.cpp
basic_op_new.cpp
basic_op_sub.cpp
basic_pro.cpp
default_io.cpp
ofmt.cpp

could you comment out the corresponding #include line in each of these files and check that re-compilation goes well? (it does, for me).
All this is a bit murky.

hivon · 2020-03-25T18:26:48Z

Hi @GillesDuvert, I tried commenting out the #include "datatypes.hpp"
lines in those files, but it does not help.
@alaingdl: when I try to use clang instead of genuine gcc, I get a problem with graphicsmagick.
Eric

alaingdl · 2020-03-25T18:30:13Z

same for me : if commented, compilation OK with Clang, failed with GCC

@hivon: same than me :( cmake ..... -Dmagick=off just for tests ?!

alaingdl · 2020-03-25T21:00:26Z

few tools : doxygen, a tool in clang, cppclean by Google.

https://stackoverflow.com/questions/614794/detecting-superfluous-includes-in-c-c

alaingdl · 2020-03-31T00:40:08Z

I spend some time on this issue last week

commenting #include "datatypes.hpp as @GillesDuvert suggested was not enough
cppclean crashed after processing tens of files
I did not succeed to run the tool in Clang

I plan to come back on OSX soon because my test-bed is back online :)

alaingdl · 2020-06-09T19:06:21Z

working today on that with the help of Eric, thanks.

 CC=gcc-8 CXX=g++-8 cmake .. -DPYTHON=OFF -DOPENMP=OFF  -DGEOTIFF=OFF  -DSHAPELIB=OFF -DREADLINEDIR=/usr/local/opt/readline  -DWXWIDGETS=OFF -DHDF=OFF -DHDF5=OFF -DUDUNITS2=OFF  -DPSLIB=OFF -DGRIB=off -DGLPK=OFF -DGRAPHICSMAGICK=off

gives :

[...]
duplicate symbol typeinfo for Data_<SpDLong64> in:
    CMakeFiles/gdl.dir/datatypes.cpp.o
    CMakeFiles/gdl.dir/ifmt.cpp.o
[...]
duplicate symbol typeinfo name for Data_<SpDLong64> in:
    CMakeFiles/gdl.dir/datatypes.cpp.o
    CMakeFiles/gdl.dir/ofmt.cpp.o
[...]

alaingdl · 2020-06-09T20:12:50Z

maybe it is related to lines around 217 in datatypes.hpp with :

#    if defined(__clang__)
#      pragma clang diagnostic ignored "-Wunsupported-friend"
[...]

GillesDuvert · 2020-06-10T08:42:35Z

The C++ code is indeed a bit convoluted. Splitting the huge datatypes file was too easy to be honest 😄 It seems that some linkers are less regarding than others, because indeed in the current state compiling two .cpp files create duplicate symbols for the same things. When the linker is accomodating, things go well and the fact that Data_<> is defined twice is transparent as the definition is the same. But this definitely needs to be sorted out.

slayoo · 2020-06-10T08:45:13Z

should we then wait with rc3 till solving it?

alaingdl · 2020-06-10T08:52:16Z

Ok for me. Wait rc4 ! I would say, as long as it's compiling fine for me on 10.14.4 with CLang on the same machine, and CLang is present by default, it is more or less non blocking.

The problem with 10.15.4 and X11 #780 is more annoying for me

GillesDuvert · 2020-06-10T13:26:45Z

Still no wxWidgets on MacOS?

alaingdl · 2020-06-10T13:33:40Z

I don't know ! I have no way to test.
I don't have one physically. Just I use remotely some OSX, and just have some problems to have basic tcl-tk (zenity) or others tools. Even IDL (& widgets in IDL) remotely is bad on OSX for me (except basic plots) through the network.

GillesDuvert · 2020-06-10T17:37:07Z

how about removing
template<class> class Data_;
at line 279 in basegdl.hpp ?

alaingdl · 2020-06-10T17:40:23Z

I can try, but later ! this evening

slayoo · 2020-06-10T17:59:04Z

how about removing
template<class> class Data_;
at line 279 in basegdl.hpp ?

FWIW, compilation OK on my Debian laptop with gcc 8.3

alaingdl · 2020-06-10T18:22:14Z

(waiting from my oven)

not working for me :( (osx + gcc version 8.2.0 (Homebrew GCC 8.2.0) )

GillesDuvert · 2020-06-10T18:33:16Z

not working means what? does not compile (should, as it compiles with linux+gcc) or has the same duplicate symbol problem as above?

alaingdl · 2020-06-10T19:39:13Z

Sorry. Same duplicate symbols (compilation goes to the end)

GillesDuvert · 2020-06-11T17:28:37Z

everything is explained here.
Now, will try some new tests...

GillesDuvert · 2020-06-11T20:46:24Z

@acoulais, coudl you try with:

instantiate_templates.hpp as such:

#ifndef INSTANTIATE_TEMPLATES_HPP_
#define INSTANTIATE_TEMPLATES_HPP_

inline template class Data_< SpDByte>;
inline template class Data_< SpDInt>;
inline template class Data_< SpDUInt>;
inline template class Data_< SpDLong>;
inline template class Data_< SpDULong>;
inline template class Data_< SpDLong64>;
inline template class Data_< SpDULong64>;
inline template class Data_< SpDPtr>;
inline template class Data_< SpDFloat>;
inline template class Data_< SpDDouble>;
inline template class Data_< SpDString>;
inline template class Data_< SpDObj>;
inline template class Data_< SpDComplex>;
inline template class Data_< SpDComplexDbl>;
#endif

and 2) the end of datatypes.cpp modified such as:

  return Real2Int<SizeT,double>(real((*this)[i]));
}
template class Data_< SpDByte>;
template class Data_< SpDInt>;
template class Data_< SpDUInt>;
template class Data_< SpDLong>;
template class Data_< SpDULong>;
template class Data_< SpDLong64>;
template class Data_< SpDULong64>;
template class Data_< SpDPtr>;
template class Data_< SpDFloat>;
template class Data_< SpDDouble>;
template class Data_< SpDString>;
template class Data_< SpDObj>;
template class Data_< SpDComplex>;
template class Data_< SpDComplexDbl>;

//#include "instantiate_templates.hpp"

pls notice the #include instantiate template is commented out 😄

alaingdl · 2020-06-11T21:10:50Z

I think I made the tests as carefully as I can (on a new copy of the master)

on the CLang side, I received 14 warnings !

/Users/coulais/GDL/gdl-1.0.0rc2-git200611CMake/src/instantiate_templates.hpp:33:1: warning: ignoring 'inline' keyword
      on explicit template instantiation [-Wstatic-inline-explicit-instantiation]
inline template class Data_< SpDComplex>;
^

but the compilation succeed.

on the GCC side, no

duplicate symbol typeinfo name for Data_<SpDLong64> in:
    CMakeFiles/gdl.dir/datatypes.cpp.o
    CMakeFiles/gdl.dir/ofmt.cpp.o
duplicate symbol typeinfo for Data_<SpDLong64> in:
    CMakeFiles/gdl.dir/datatypes.cpp.o
    CMakeFiles/gdl.dir/ofmt.cpp.o
ld: 252 duplicate symbols for architecture x86_64
collect2: error: ld returned 1 exit status

GillesDuvert · 2020-06-11T21:42:11Z

Too bad.
In retrospect, according to documentation above the code as it was should never have caused trouble to begin with, since the so-called 'Borland model' is imlemented by GCC on Mac OS X.
so, what about removing

#if defined(__GNUC__) && !defined(__INTEL_COMPILER)
// by default intel C++ defines __GNUC__
#pragma interface
#endif

at lines 29-32 from datatypes.hpp

(i precise that every of the above changes produces always a correct compilation and code on my side, linux+gcc 8.4.0)

alaingdl · 2020-06-11T21:59:12Z

Yes, I played in this region yesterday, tryng to add similar flags than clang ones

I will try now

alaingdl · 2020-06-11T22:10:58Z

nop 👎 before, it was only 252 duplicate, now : ld: 1260 duplicate symbols for architecture x86_64

what is strange for me is that we have other machines with GCC 7, 8, 9 and no problem. Only problem here with this special compiler :(
Since it is provided by Brew (cellar ..) may be it needs an update ?
Or maybe a flag is missing, of CMake don't set it up well ?

GillesDuvert · 2020-06-12T08:40:13Z

Yes, I would say the GDL code passes almost everywhere because the compilers are quite friendly.
The template instantiation duplication is between datatypes.cpp and ofmt.cpp etc. This can probably be cured by declaring 'extern' instead of 'inline' in instantiate_templates and remove from datatypes.hpp the definitions that are in conflict, while providing them for all the code that refer to them. Some work.

GillesDuvert · 2020-06-17T16:41:00Z

@alaingdl or @hivon, does this branch compile ?

opoplawski · 2020-06-19T04:14:30Z

Still fails for me on Fedora Rawhide on 32-bit arm:
https://kojipkgs.fedoraproject.org//work/tasks/2162/45842162/build.log

GillesDuvert · 2020-06-19T07:34:40Z

@opoplawski thank you, that was a pitiful attempt on my side. Unfortunately compiling the base gdl objects menagerie when they are templated in so many files & includes needs skills I do not have.

GillesDuvert · 2021-03-17T23:07:53Z

please have a try now that #882 is merged

GillesDuvert · 2024-03-09T10:46:13Z

closed by #1776

GillesDuvert added a commit to GillesDuvert/gdl that referenced this issue Jun 17, 2020

test if solve gnudatalanguage#734 and related

4babaa1

GillesDuvert mentioned this issue Jun 20, 2020

packaging 1.0.0-rc3 (was: packaging 1.0.0-rc2) #761

Closed

GillesDuvert added the duplicate_symbol label Mar 20, 2021

GillesDuvert mentioned this issue Aug 5, 2021

question about "#include "instantiate_templates.hpp" & duplicate symbol #1046

Closed

GillesDuvert mentioned this issue Mar 2, 2024

OSX: performance issues within Clang + duplicate symboles with g++-13 #1755

Closed

GillesDuvert closed this as completed Mar 9, 2024

duplicate symbol typeinfo under MacOS #734

duplicate symbol typeinfo under MacOS #734

Comments

hivon commented Mar 24, 2020

alaingdl commented Mar 25, 2020

GillesDuvert commented Mar 25, 2020

alaingdl commented Mar 25, 2020

hivon commented Mar 25, 2020

alaingdl commented Mar 25, 2020 • edited Loading

GillesDuvert commented Mar 25, 2020

hivon commented Mar 25, 2020

alaingdl commented Mar 25, 2020

alaingdl commented Mar 25, 2020 • edited Loading

alaingdl commented Mar 31, 2020

alaingdl commented Jun 9, 2020

alaingdl commented Jun 9, 2020

GillesDuvert commented Jun 10, 2020

slayoo commented Jun 10, 2020

alaingdl commented Jun 10, 2020

GillesDuvert commented Jun 10, 2020

alaingdl commented Jun 10, 2020

GillesDuvert commented Jun 10, 2020

alaingdl commented Jun 10, 2020

slayoo commented Jun 10, 2020

alaingdl commented Jun 10, 2020

GillesDuvert commented Jun 10, 2020

alaingdl commented Jun 10, 2020

GillesDuvert commented Jun 11, 2020

GillesDuvert commented Jun 11, 2020

alaingdl commented Jun 11, 2020

GillesDuvert commented Jun 11, 2020

alaingdl commented Jun 11, 2020

alaingdl commented Jun 11, 2020

GillesDuvert commented Jun 12, 2020

GillesDuvert commented Jun 17, 2020

opoplawski commented Jun 19, 2020

GillesDuvert commented Jun 19, 2020

GillesDuvert commented Mar 17, 2021

GillesDuvert commented Mar 9, 2024

alaingdl commented Mar 25, 2020 •

edited

Loading

alaingdl commented Mar 25, 2020 •

edited

Loading