search

gerddie / gentoo-imaging

Gentoo overlay for image processing software
GNU General Public License v3.0
6 stars 6 forks source link

sci-libs/gdcm: building with system openjpeg fails #3

Closed billyonthemountain closed 8 years ago

billyonthemountain commented 8 years ago

Its seems there are several API discrepancies between the bundled openjpeg and the system version. I tried several combination between 1.5.0-r1, 1.5.2-r1, 2.0.1-r1 and 2.1.0-r1 but to no avail. Any idea ?

Workaround : build with GDCM_USE_SYSTEM_OPENJPEG:BOOL=OFF

gerddie commented 8 years ago

No idea, I have 2.1.0 (-doc -static-libs -test) on amd64 with gdcm-2.6.3 and it builds without a hitch (g++-5.3.0). In Debian we are still at openjpeg-1.5.2, but there are also no open bugs related to this.

gerddie commented 8 years ago

Well, I now compiled gdcm-2.6.3 against openjpeg-2.1.0-r1 (which introduces multilib) and it also worked.

gerddie commented 8 years ago

I was wrong in one thing: gdcm actually compiled against openjpeg-1.5.2, testing 1.5.2-r1 now.

gerddie commented 8 years ago

Well, this also compiles without problems. Could you post the log of the failing build?

billyonthemountain commented 8 years ago

Here it is. Build is against openjpeg-2.1.0-r1. It resembles in many regards debian bug #801228.

gerddie commented 8 years ago

I see. This is very strange, because I have both (1.5.2 and 2.1.0) installed. So my guess is that gdcm doesn't support to be build against 2.X and when both are installed, then it might pick one randomly. I'll investigate how the version of openjpeg is selected and see whether I can fix it.

billyonthemountain commented 8 years ago

Looking at the errors, many of the symbols are missing the OPJ_ prefix introduced in commits 21b0ccf and 84c93c2 prior to version 2.0. The prototype change of opj_stream_set_user_data come from commit 7aece5e (introduced for version 2.1). For opj_decode: commit 3f9fb13.

It seems the same issue hit FreeBSD; opj_get_reversible never existed in openjpeg's codebase. I'll try to port their patches and report back.

gerddie commented 8 years ago

Okay, found it. The FindOpenJPEG implemented in gdcm searched simply for the file openjpeg.h and deducts the include path from this. Which is used depends on on whether it firsts finds the one from version 1.5 or the one from version 2.1. I'll report this to gdcm upstream and think about how CMake can be made to select a specific openjpeg version.

gerddie commented 8 years ago

Reported. BTW, there is also request to support 2.1.0.

Currently, the FindOpenJPEG.cmake file searches only for the library name openjpeg, which indicates 1.X series, so when you port gdcm to use 2.1, this must also be changed.