When extern/libopenjpeg is same version as here, Id say good to go. (or extern is dropped, please ;) )
And yes, might be hell to build these by hand for 10.6

imbuf/intern/jp2.c needs also some love because of API changes.

In D3005#71230, @Arto Kitula (akitula) wrote:

imbuf/intern/jp2.c needs also some love because of API changes.

@Arto Kitula (akitula) This is done in temp-openjpeg23 branch

In D3005#71236, @Campbell Barton (campbellbarton) wrote:

@Arto Kitula (akitula) This is done in temp-openjpeg23 branch

Oh, missed that one. =) We're good then.

Note, OPJ_DISABLE_TPSOT_FIX needs to be defined, otherwise it wont read files written by Blender, see: https://github.com/uclouvain/openjpeg/issues/254

Found root cause, fixed in temp-openjpeg23 - rB9e0a2db32563

@Campbell Barton (campbellbarton) @Brecht Van Lommel (brecht) how about landing this? Or shall we split blender side from build_environment first and land all changes to blender when svn libs are all updated?

This can't be split up, due to openjpeg living both in the binary deps and lives in /extern they have to match and be of the same version or the linker will have a bad time linking oiio (atleast on windows, but i can't imagine mac would be any different)

also we could bump the following libs a little further if we wanted to

libpng 1.6.21(current)	->1.6.32(D3005)	->1.6.34(Latest)
ffmpeg 3.2.1(current)	->3.4.1(D3005)	->4.0.2(Latest)
webp 0.5.1(current)	->0.6.1(D3005)	->1.0.0(Latest)

+1 for bump up to latest.

I was thinking that we could do all build_environment cmake updates first, and when they're all ready, actually upload libs to svn and commit changes to blender side. Just to minimize svn updates and needs to build old oiio and then new again later... removing openjpeg from external at the same time.

I'm fine with updating the build environment files first, though I also see no big issue updating e.g. OIIO multiple times if it helps in some way.

@Arto Kitula (akitula) and @Ray Molenkamp (LazyDodo), I think you can just coordinate the Windows and macOS + CMake files updates amongst yourselves, and then Sergey does the Linux part later. See also my mail to bf-committers.

For OpenJPEG, I've committed rB440ef4235ff0: OpenJPEG: support building against both 1.5 and 2.3.. On macOS we already force WITH_SYSTEM_OPENJPEG, and Windows can do the same so that the version in extern/ is not used.

Any reason to keep the openjpeg in extern/ ?

Think it would be nice if we could get rid of too many big libraries which are well maintained externally.

I have brought up cleaning up /extern i the past, and from what I get it's mostly there as a convenience for the linux platform, i'm kinda digging the WITH_SYSTEM_* thing and wouldn't mind transferring some of the libs in /extern that have no local changes (like ceres) over to svn once we finish the current batch of lib updates. That way linux users can still have the code easily available in the version we like, but the mac/windows users don't have to build the same thing that never changes over and over again (last time i checked ceres alone was about 12% of the complete blender build time)

I'm not aware of any reason to keep OpenJPEG in extern/ once we have upgraded all platforms to the new version. Some more cleaning of extern/ later seems reasonable too.