Closed barracuda156 closed 1 year ago
__ZNK2H58CompType12insertMemberERKSsmRKNS_8DataTypeE
should be part of /opt/local/lib/libhdf5_cpp.dylib
which I see you are linking. See https://docs.hdfgroup.org/archive/support/HDF5/doc1.8/cpplus_RM/class_h5_1_1_comp_type.html#ab093b060861eec6209928da5b7792a1a. Can you check whether that symbol is available?
Is there a mismatch between your headers and libraries in /opt/local
? Also, are you using the same compiler for building kealib
that you used for hdf5
?
@gillins Thank you for responding! That was quick.
Also, are you using the same compiler for building kealib that you used for hdf5?
Yes in a sense of GCC version, but HDF5
uses MPICH wrappers, while kealib
does not.
Headers and libs must come from the same versions, Macports won’t allow a conflict. And we do not have multiple versions for gdal
and HDF5
which can be installed simultaneously (some libraries do).
I will check symbols now.
@gillins I suspect HDF5 did not have -D_GLIBCXX_USE_CXX11_ABI=0
passed, and in result we have all these cxx11
among symbols:
36-25% nm -arch ppc -g /opt/local/lib/libhdf5_cpp.310.dylib | grep __ZNK2H58CompType
00025d54 T __ZNK2H58CompType11getNmembersEv
0002636c T __ZNK2H58CompType12insertMemberERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEmRKNS_8DataTypeE
00025e2c T __ZNK2H58CompType13getMemberNameB5cxx11Ej
0002602c T __ZNK2H58CompType14getMemberClassEj
00025f38 T __ZNK2H58CompType14getMemberIndexEPKc
00026014 T __ZNK2H58CompType14getMemberIndexERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE
0002601c T __ZNK2H58CompType15getMemberOffsetEj
00026a4c T __ZNK2H58CompType16getMemberIntTypeEj
00026d0c T __ZNK2H58CompType16getMemberStrTypeEj
000261f0 T __ZNK2H58CompType17getMemberCompTypeEj
0002662c T __ZNK2H58CompType17getMemberDataTypeEj
000268ec T __ZNK2H58CompType17getMemberEnumTypeEj
00026108 T __ZNK2H58CompType17p_get_member_typeEj
0002678c T __ZNK2H58CompType18getMemberArrayTypeEj
00026bac T __ZNK2H58CompType18getMemberFloatTypeEj
00026e6c T __ZNK2H58CompType19getMemberVarLenTypeEj
00026474 T __ZNK2H58CompType4packEv
00025a4c T __ZNK2H58CompType6decodeEv
0002654c T __ZNK2H58CompType7setSizeEm
00026fcc T __ZNK2H58CompType9fromClassB5cxx11Ev
That would explain why it is broken.
Yep indeed would explain it. Where does -D_GLIBCXX_USE_CXX11_ABI=0
come from? Are you specifying it manually?
Yep indeed would explain it. Where does
-D_GLIBCXX_USE_CXX11_ABI=0
come from? Are you specifying it manually?
Honestly I am not too sure, it is either Macports base or cmake PortGroup passing it depending on the OS version and possibly runtime or/and compiler used. It does not always work automatically though, and sometimes we have to add the flag manually.
I have encountered these errors a number of times, so I know that whenever I see cxx11
in symbol names in linking errors, solution is to pass -D_GLIBCXX_USE_CXX11_ABI=0
in cxxflags. Usually these errors occur during the build of a given port though. Here, however, HDF5 itself built fine, but we cannot link to it :)
I have opened a ticket on Trac, we will fix it soon, I guess: https://trac.macports.org/ticket/67893
Thank you for a helpful suggestion where to look!
macports supplies this flag automatically when building for c++11 or greater while using gcc, to ensure compatibility with older gcc libraries installed on the system.
this is specified in macports using a specific command:
compiler.cxx_standard 2011
This and other similar commands are specified here
https://trac.macports.org/wiki/CompilerSelection
MacPorts is simple to begin to use, but sometimes the more complex features take longer for new users like @barracuda156 to fully grasp. We’ll continue to help.
If one library has been built using c++11 names and features, then often other software that uses that library likewise needs to be built using c++11 names.
by the way, you should never pass -D_GLIBCXX_USE_CXX11_ABI=0 manually in cxxflags by yourself…. other necessary things need to happen, done by passing the correct Portfile command, as above.
by the way, you should never pass -D_GLIBCXX_USE_CXX11_ABI=0 manually in cxxflags by yourself…. other necessary things need to happen, done by passing the correct Portfile command, as above.
@kencu Well, I am not planning to touch HDF5, let maintainers fix that, but automatic passing of -D_GLIBCXX_USE_CXX11_ABI=0
with GCC and C++11 or higher does not always work, FWIW. For example, our R
PG sets C++11 standard: https://github.com/macports/macports-ports/blob/10fb167dd282b4d39ed8290b21e26623ad6f33f0/_resources/port1.0/group/R-1.0.tcl#L72
Yet a number of R
ports were broken unless -D_GLIBCXX_USE_CXX11_ABI=0
passed explicitly (not numerous, but perhaps a dozen or so out of 3500).
it is added by macports base to the cxxflags if the above commandviscin the portfile and gcc is the compiler.
So that always works.
Whether the build is set up correctly, properly uses it, etc, is another matter.
If you THINK you need to manually add that flag, you don’t… you have another unresolved build issue that needs fixing, not adding that flag manually.
all things you will learn after being in macports awhile… I’ve been there so long now, I wrote that code when it was part of the cxx11 Portgroup (and then later it was integrated in macports-base).
this has nothing to do with kealib, by the way, it is 100% a MacPorts issue to resolve
Any idea why this fails?