Add ITKCommon_EXPORT macro in the declaration of inlined Zero in NumericTraits

[grizonnetm]

commit 3ed8e8a in itk NumericTraits leads to compilation error in orfeo toolbox.

I was able to solve them adding ITKCommon_EXPORT macro in the declaration. Not sure to understand why it is necessary as the related commit in ITK seems to handle linkage resolution.

The link error related to new declaration of inlined Zero for integers type can be seen on otb dashboard:

http://dash.orfeo-toolbox.org/viewBuildError.php?buildid=225288

Configurations for ITK and OTB which leads to the linking issue can also be found on otb git repositories:

itk configuration:

https://git.orfeo-toolbox.org/otb-devutils.git/blob/HEAD:/Config/pc-christophe/pc-christophe-ITK-trunk.cmake

otb configuration:

https://git.orfeo-toolbox.org/otb-devutils.git/blob/HEAD:/Config/pc-christophe/pc-christophe-OTB-Nightly-clang-ThirdPartyTrunk.cmake

[blowekamp]

Thank you for including that configuration file.

You appear to be using clang on Fedora 22. What version of clang? Are you building shared libraries?

There are a lot of OTB flags. Can you please provide an ITK configuration to reproduce the error.

With C++11 and constexpr the need for export should not be there. Do you still get the error with "-std=c++11" flag? Does you change work OK with this flag?

[grizonnetm]

Thanks for reviewing the patch.

ITK trunk is compiled on Fedora 22 with GCC (5.3.1, system package). Flags used for the configuration:

CMAKE_CXX_FLAGS:STRING=-fPIC -Wall -Wextra -Wunused-local-typedefs
CMAKE_C_FLAGS:STRING=-fPIC -Wall -Wextra

The ITK configuration can be found in the commit message and is available in otb scripts repo:
https://git.orfeo-toolbox.org/otb-devutils.git/blob/HEAD:/Config/pc-christophe/pc-christophe-ITK-trunk.cmake

OTB is compiled with clang 3.5.0 (system package on fedora 22):

CMAKE_C_COMPILER=/usr/bin/clang
CMAKE_CXX_COMPILER=/usr/bin/clang++
CMAKE_C_FLAGS:STRING=-Wall
CMAKE_CXX_FLAGS:STRING=-Wall -Wno-gnu-static-float-init -Wno-\#warnings -Wno-unknown-attributes

I suspect that the error will not appear with "-std=c++11" flag but I did not check my patch with it. Indeed something to do...

Note that what I've found investigating the issue with 'nm' command:

• without my patch: Zero symbols are in a read only data section local marked 'r' (lowercase)
  • with the patch : still in a read only data section but global, marked 'R' (uppercase)

I confirm that the patch solve the issue on otb dashboard:

http://dash.orfeo-toolbox.org/buildSummary.php?buildid=225558

Side question, is it on the ITK roadmap to only support compiler with c++11 activated?

[blowekamp]

I am surprised that this error is not showing up on the ITK dashboard. Is there a minimal code example that is required to reproduce this error?

I have a patch up for review that extends the testing for these variables, that may be what triggered this error in your code.

http://review.source.kitware.com/#/c/21050/

[grizonnetm]

Actually I'm not able to reproduce the issue with a minimal code example yet :(

There must be something related to the way that OTB link with ITK. ITK is added to OTB as a module (following itk modularity architecture):

https://git.orfeo-toolbox.org/otb.git/tree/HEAD:/Modules/ThirdParty/ITK

A bit stuck now with this...

[blowekamp]

With that test patch I added, I think we are now getting the error on the dashboard. Only one machine which runs valgrind:
gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-4)
Debug
Shared Libraries.

[grizonnetm]

Ouf!

I've got a simple example only based on ITK which allows to reproduce the problem above.

`#include "itkImage.h"

int main()
{
const unsigned int Dimension = 2;
typedef unsigned char PixelType;

const PixelType val = itk::NumericTraits::Zero;

typedef itk::Image<PixelType, Dimension> ImageType;

ImageType::Pointer image = ImageType::New();

image->FillBuffer(itk::NumericTraits::Zero);

return EXIT_SUCCESS;
}
`

Note that only declaring a const PyxelType val = itk::NumericTraits<PixelType>::Zero will not triggered the link error.

I can reproduce the error only with clang (not with gcc).

[blowekamp]

I presume it needs to be shared. Does Debug vs Release matter?

[grizonnetm]

Debug vs Release does not matter. What's really matter in my test case seems to be the compiler.

What needs to be shared? the ITK build?

[thewtex]

Thanks for patch! This has been pushed to Gerrit and merged:

http://review.source.kitware.com/#/c/21085/