[gdal-dev] Add capability to safely link against an external libtiff (3.X) and a GDAL build with internal libtiff (4.0) support

[Even Rouault]

Le vendredi 22 juillet 2011 17:54:03, Julien Malik a écrit :
> Hello,
> 
> A little late, but I report success in the tests I ran so far.
> None of our problematic test cases causes an error anymore.
> In the future I should be more reactive, as I have set up a platform
> testing OTB built on top of the gdal trunk, on a nightly basis.

Great

> 
> I still have one last test to run for a final confirmation (building the
> OTB QGis plugins, where the crash was inevitable, despite the handling
> of the link order which bypassed the problem for executable). But I'm
> confident from the results of the other tests...
> 
> Many thanks for this long-awaited fix !
> Julien
> 
> PS: Do you think this renaming option could be pushed upstream to
> libtiff and libgeotiff (maybe not as-is) ?
> It would save GDAL the burden of maintaining a patch in its internal
> versions, and it would benefit other projects integrating those libs in
> their source.

Not sure if the said upstream projects would be interested (*) by such an 
option (it changes their API !), and especially in its current 
"implementation". And I don't know how it could be made cleaner. Anyway, I'm 
afraid I lack the energy/interest to pursue on this myself, so I'll let 
happily anyone interested in it to do it.

As far as libtiff is concerned, I personnaly think the most important item is 
to find the magic incantation so it can be finally labelled 4.0.0 and be adopted 
by the large crowds that stay away from something called "beta". Then --with-
libtiff=internal won't be necessary.

> FYI I'm currently working on a similar patch for openjpeg,
> allowing to choose the renaming prefix at configuration time.

And how do you establish the list of symbols to rename ? At configuration time 
too ?


(*) CC'ing a commiter of both projects ;-)