On LINUX: '-DBUILD_JAVA:bool=on -DBUILD_THIRDPARTY:bool=on'.
'-DBUILD_SHARED_LIBS:bool=off' creates 'libopenjpeg.a':
Linking C shared module ../../bin/libopenjpegjni.so
----------------------------------------
/usr/lib64/gcc/x86_64-slackware-linux/4.8.2/../../../../x86_64-slackware-linux/b
in/ld: ../../bin/libopenjpeg.a(cio.c.o): relocation R_X86_64_32 against
`.rodata.str1.8' can not be used when making a shared object; recompile with
-fPIC
../../bin/libopenjpeg.a: could not read symbols: Bad value
collect2: error: ld returned 1 exit status
make[2]: *** [bin/libopenjpegjni.so] Error 1
make[1]: *** [applications/JavaOpenJPEG/CMakeFiles/openjpegjni.dir/all] Error 2
make: *** [all] Error 2
----------------------------------------
Adding in the top 'CMakeLists.txt' file just below the line:
ENDIF(CMAKE_COMPILER_IS_GNUCC)
these three lines:
IF(UNIX)
SET(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -fPIC")
ENDIF(UNIX)
is enough. Now ALL static libraries have POSITION INDEPENDENT CODE
and can be linked with the 'libopenjpegjni.so' file.
The same holds for the 'openjpeg-2.x-branch-r2881', but the context
is different: the JAVA code is broken. If the developers should
replace the broken code with the code user Boxer proposed in
his archive 'openjpeg-java_imageio' then the static libraries of
the THIRDPARTY directory are linked to 'libopenjpegjni.so' and
must fail without '-fPIC'; but succeed with '-fPIC'.
winfried
Original issue reported on code.google.com by szukw...@arcor.de on 17 Sep 2014 at 8:17
Original issue reported on code.google.com by
szukw...@arcor.deon 17 Sep 2014 at 8:17