libtiff: update to 4.7.0

[blowekamp]

PR Checklist

• No API changes were made (or the changes have been approved)
• No major design changes were made (or the changes have been approved)
• Added test (or behavior not changed)
• Updated API documentation (or API not changed)
• Added license to new files (if any)
• Added Python wrapping to new files (if any) as described in ITK Software Guide Section 9.5
• Added ITK examples for all new major features (if any)

Refer to the ITK Software Guide for
further development details if necessary.

[dzenanz]

Generally looks good. Do you plan to do an update to 4.7.0 now, or is that left for later?

[blowekamp]

Generally looks good. Do you plan to do an update to 4.7.0 now, or is that left for later?

I think it will be done in this PR.

VTK's 4.6.0 changes were used and were committed in the same sub-tree as upstream. However this changes get clobbered when the updating to 4.7.0. I believe that the merge of the VTK changes need to be "flattened" so that they are in the main ITK tree.

@bradking How do you suggest fixing the history so that updating to 4.7.0 will not remove the VTK changes?

[bradking]

I don't think we should import into ITK from VTK's third-party repo. I'll rebuild this to make the net changes directly.

[blowekamp]

I don't think we should import into ITK from VTK's third-party repo. I'll rebuild this to make the net changes directly.

I did a "git cherry-pick -m 1 7408285" and that seemed to "flatten the merge into a single parent commit.

EDIT: Just updated the PR with that WIP.

[bradking]

@blowekamp I rebuilt your PR to update directly from upstream tiff 4.7.0 and apply ITK-specific build system edits.

[bradking]

@blowekamp if there are any problems in CI, you can just edit the last commit or add new commits.

This needs to be merged with a real merge commit and no rebase or squash. Then future updates with Modules/ThirdParty/TIFF/UpdateFromUpstream.sh should merge upstream changes into our local edits.

[blowekamp]

@blowekamp if there are any problems in CI, you can just edit the last commit or add new commits.

This needs to be merged with a real merge commit and no rebase or squash. Then future updates with Modules/ThirdParty/TIFF/UpdateFromUpstream.sh should merge upstream changes into our local edits.

Amazing work!

How was the name mangling generated? Does it still need to be run on other systems?

Also It looks like libtiff.def needs to be converted to a "cmake.in" to support @MANGLE_PREFIX@?

Also the libtiff.map file has the unmagled names but it looks like the file is not used and can be removed.

[bradking]

itk_tiff_mangle.h.in has comments at the top (left from long ago) that describe how to generate the mangling. We don't actually replace @MANGLE_PREFIX@ with anything besides itk_tiff, but that pattern is used throughout ITK's third-party library mangling so I kept it. For libtiff.def I think we can leave it hard-coded.

I'll rebuild the branch with libtiff.map not imported, but we might as well let CI finish first to see if there are any other problems.

[blowekamp]

itk_tiff_mangle.h.in has comments at the top (left from long ago) that describe how to generate the mangling.

Some have been adamant that these command must be run on all platforms to ensure all symbols have been identified. So what platform(s) was it run on?

We don't actually replace @MANGLE_PREFIX@ with anything besides itk_tiff, but that pattern is used throughout ITK's third-party library mangling so I kept it. For libtiff.def I think we can leave it hard-coded.

This is the commit that introduced it:
a3afcf6

My understanding is that 3D Slicer has multiple version of ITK in the runtime. ( ITK Python for pip and local build?) and there were problems with conflicting symbols. Additionally, missing mangled symbols with third partly libraries have caused problems.

[bradking]

Okay, I pushed an update to drop the .map file and convert the .def file to use @MANGLE_PREFIX@.

The mangling currently accounts for Windows, macOS, and Linux.

[seanm]

Some have been adamant that these command must be run on all platforms to ensure all symbols have been identified.

I've seen this in the past, with HDF5 I think, which both VTK and ITK use, where the mangling was done only with some OSes and some symbols where missed, and then both VTK and ITK have the same symbol and you get a link error.

95% of symbols are of course shared between OSes, but that 5% has bitten us in the past.

[blowekamp]

@bradking Thanks for all the work!

I checked the symbols an my Mac ARM and nothing were missing. I did have to modify the commands to make the symbols unique and sort them with case insensitivity ( but there were still order difference). I also build from an installed version of ITK successfully too.

[hjmjohnson]

@bradking @blowekamp THANK YOU FOR YOUR HARD WORK!!!

Hans