A single build method for OpenJPEG 2.x

[Antonin Descampe]

Dear openjpeg users,

As you (may) know, OpenJPEG v2.0 will be released soon. We hope it will be useful to as many projects as possible.

We take the opportunity of this release to standardize the names of functions and executables, change the file structure ... and simplify the build methods.

Indeed, the management of two build methods in parallel has become too complicated and we prefer to invest the limited resources we have in improving the library performances.

From version 2, we will propose only CMAKE as build method. So we abandon the AUTOTOOLS maintenance. We chose CMAKE because it is a cross-platform build method, very widespread, and it is therefore the best compromise between ease of project management and dissemination of the library. Thanks a lot to all contributors (mainly Vincent Torri, Winfried, Rex Dieter) for having provided their time and know-how to the autotools management until version 1.5.1. We hope that you guys will continue to contribute to the project on other topics now :-).

We hope you understand this decision and that you will be satisfied with the soon-to-be-released version 2!

Cheers,

Antonin

[szuk...@arcor.de]

On Sun, 30 Sep 2012 20:27:39 +0200, Antonin wrote:

>Indeed, the management of two build methods in parallel has
>become too complicated and we prefer to invest the limited
>resources we have in improving the library performances.
>
>From version 2, we will propose only CMAKE as build method.
>So we abandon the AUTOTOOLS maintenance.

In file included
from /home/szukw000/openjpeg-trunk-r2011/src/lib/openjp2/openjpeg.h:91:0,
from /home/szukw000/openjpeg-trunk-r2011/src/lib/openjp2/opj_includes.h:90,
from /home/szukw000/openjpeg-trunk-r2011/src/lib/openjp2/bio.c:32:
/home/szukw000/openjpeg-trunk-r2011/src/lib/openjp2/opj_stdint.h:56:2:
error: #error SSIZE_T is undefined
make[2]: *** [src/lib/openjp2/CMakeFiles/openjp2.dir/bio.c.o] Error 1
make[1]: *** [src/lib/openjp2/CMakeFiles/openjp2.dir/all] Error 2
make: *** [all] Error 2

The AUTOTOOLS build method has been safe.
The CMAKE build method always has been unsafe.

winfried

[szuk...@arcor.de]

On Mon, 1 Oct 2012 12:28:59 +0200, Mathieu wrote:

>That's very interesting. Could you please let us know which version of
>cmake/Os/compiler are you using ?

Future error reports will always contain these lines.

cmake version 2.8.7
Linux 3.5.3 64-Bit
gcc (GCC) 4.5.2

The bug is not dependent on cmake/Os/compiler but the the scripts.
The CMakeLists.txt files are buggy.

winfried

[Mathieu Malaterre]

Dear winfried,

I understand that you are seeing something wrong on your side. However
without *any* help from you, I cannot be of much help. Please consider
that automated tests machines are all working fine over here, there is
something specific to *your* setup.

As a personal note, I would suggest you (re)read the excellent page:
How To Ask Questions The Smart Way:

http://www.catb.org/~esr/faqs/smart-questions.html

In particular I am thinking of:

http://www.catb.org/~esr/faqs/smart-questions.html#beprecise

Thanks for your attention,
--
Mathieu

[szuk...@arcor.de]

On Mon, 1 Oct 2012 12:37:02 +0200, Mathieu wrote:

>What is even more odd is that this is a patch from you:

That patch was for the AUTOTOOLS build.

>What cmake command line did you use ?

#!/bin/sh
cmake -DCMAKE_BUILD_TYPE:string="Release" -DBUILD_SHARED_LIBS:bool=on -DBUILD_MJ2:bool=on -DBUILD_JPWL:bool=on -DBUILD_JPIP:bool=on -DCMAKE_INSTALL_PREFIX=/usr/local/CMAKE-r2011 ..

winfried

[Mathieu Malaterre]

Great ! Thanks for the bug report. Please use anything above r2016
that should do it.

You can track status update for the folder reorg proposal at:
http://code.google.com/p/openjpeg/issues/detail?id=177

Regards
--
Mathieu

[szuk...@arcor.de]

On Mon, 1 Oct 2012 12:52:16 +0200, Mathieu wrote:

>I understand that you are seeing something wrong on your side. However
>without *any* help from you, I cannot be of much help. Please consider
>that automated tests machines are all working fine over here, there is
>something specific to *your* setup.
>
>As a personal note, I would suggest you (re)read the excellent page:
>How To Ask Questions The Smart Way:
>
>http://www.catb.org/~esr/faqs/smart-questions.html
>
>In particular I am thinking of:
>
>http://www.catb.org/~esr/faqs/smart-questions.html#beprecise
>
>Thanks for your attention,

Future answers to bug reports will always contain these lines.

After applying the patch below I get:

Scanning dependencies of target openmj2
[ 24%] Building C object src/lib/openmj2/CMakeFiles/openmj2.dir/mj2.c.o
[ 25%] Building C object src/lib/openmj2/CMakeFiles/openmj2.dir/mj2_convert.c.o
Linking C shared library ../../../bin/libopenmj2.so
/home/szukw000/openjpeg-trunk-r2011/src/lib/openmj2/mj2.c: In function 'mj2_create_decompress':
/home/szukw000/openjpeg-trunk-r2011/src/lib/openmj2/mj2.c:2736:11: warning: assignment makes pointer from integer without a cast
/home/szukw000/openjpeg-trunk-r2011/src/lib/openmj2/mj2.c: In function 'mj2_create_compress':
/home/szukw000/openjpeg-trunk-r2011/src/lib/openmj2/mj2.c:2814:11: warning: assignment makes pointer from integer without a cast
/usr/lib64/gcc/x86_64-slackware-linux/4.5.2/../../../../x86_64-slackware-linux/bin/ld: cannot find -lopenjpeg
collect2: ld returned 1 exit status
make[2]: *** [bin/libopenmj2.so.1.99.0] Error 1
make[1]: *** [src/lib/openmj2/CMakeFiles/openmj2.dir/all] Error 2

make: *** [all] Error 2

winfried


--- openjpeg-trunk-r2011/src/lib/openjp2/CMakeLists.txt.orig 2012-10-01 13:17:44.060424368 +0200
+++ openjpeg-trunk-r2011/src/lib/openjp2/CMakeLists.txt 2012-10-01 13:18:08.387422815 +0200
@@ -1,4 +1,6 @@
include_regular_expression("^.*$")
+include(CheckTypeSize)
+CHECK_TYPE_SIZE(ssize_t SSIZE_T)

#-----------------------------------------------------------------------------
# opj_config.h generation (2/2)

[Mathieu Malaterre]

As said before you need to apply *all* patches before r2016, you seems
to be missing:

http://code.google.com/p/openjpeg/source/detail?r=2012

2cts
--
Mathieu

[szuk...@arcor.de]

On Mon, 1 Oct 2012 13:24:38 +0200, Mathieu wrote:


>Great ! Thanks for the bug report. Please use anything above r2016
>that should do it.

No.

winfried

Linking C executable ../../../bin/opj_mj2_compress
/home/szukw000/openjpeg-trunk-r2018/src/lib/openmj2/mj2.c: In function 'mj2_create_decompress':
/home/szukw000/openjpeg-trunk-r2018/src/lib/openmj2/mj2.c:2736:11: warning: assignment makes poiner from integer without a cast
/home/szukw000/openjpeg-trunk-r2018/src/lib/openmj2/mj2.c: In function 'mj2_create_compress':
/home/szukw000/openjpeg-trunk-r2018/src/lib/openmj2/mj2.c:2814:11: warning: assignment makes poiner from integer without a cast
/home/szukw000/openjpeg-trunk-r2018/src/bin/mj2/opj_mj2_compress.c: In function 'main':
/home/szukw000/openjpeg-trunk-r2018/src/bin/mj2/opj_mj2_compress.c:771:2: warning: passing argumet 1 of 'opj_setup_encoder' from incompatible pointer type
/home/szukw000/openjpeg-trunk-r2018/src/lib/openjp2/openjpeg.h:1423:31: note: expected 'void **' ut argument is of type 'struct opj_cinfo_t *'
CMakeFiles/opj_mj2_compress.dir/opj_mj2_compress.c.o: In function `main':
opj_mj2_compress.c:(.text+0x1912): undefined reference to `opj_set_event_mgr'
../../../bin/libopenmj2.so.1.99.0: undefined reference to `jp2_read_jp2h'
../../../bin/libopenmj2.so.1.99.0: undefined reference to `j2k_create_compress'
../../../bin/libopenmj2.so.1.99.0: undefined reference to `j2k_create_decompress'
../../../bin/libopenmj2.so.1.99.0: undefined reference to `jp2_write_jp2h'
../../../bin/libopenmj2.so.1.99.0: undefined reference to `j2k_setup_decoder'
../../../bin/libopenmj2.so.1.99.0: undefined reference to `j2k_destroy_compress'

collect2: ld returned 1 exit status

make[2]: *** [bin/opj_mj2_compress] Error 1
make[1]: *** [src/bin/mj2/CMakeFiles/opj_mj2_compress.dir/all] Error 2

[Mathieu Malaterre]

Hi,

On Mon, Oct 1, 2012 at 1:37 PM, <szuk...@arcor.de> wrote:
> No.

Yes :)

> ../../../bin/libopenmj2.so.1.99.0: undefined reference to `jp2_read_jp2h'

This is expected as part of the transition to v2. This is a different
issue from issue #177.
The old API is deprecated, someone will need to update the call within
the mj2 lib.

HTH
--
Mathieu

[szuk...@arcor.de]

The 'BUILD/bin' directory was always good for testing.

/home/szukw000/openjpeg-trunk-r2018/BUILD/bin

szukw000: ./opj_compress -i bike.png -o bike.jp2

Unable to load file: got no image

After installing:

szukw000: cd /usr/local/CMAKE-r2011/bin

szukw000: ./opj_compress -i bike.png -o bike.jp2
./opj_compress: error while loading shared libraries: libopenjp2.so.1: cannot open shared object file: No such file or directory


winfried

[Bob Friesenhahn]

The "single build method" email posting made me feel very sad. There
is a reason why portable software is using Autotools and only ported
software uses 'cmake'. There is a significant difference between
"portable" and "ported".

This is what happens for me if I use the incantation above:

% cmake -DCMAKE_BUILD_TYPE:string="Release" -DBUILD_SHARED_LIBS:bool=on -DBUILD_MJ2:bool=on -DBUILD_JPWL:bool=on -DBUILD_JPIP:bool=on -DCMAKE_INSTALL_PREFIX=/usr/local/CMAKE-r2011
-- The C compiler identification is GNU
-- Check for working C compiler: /usr/local/bin/gcc
-- Check for working C compiler: /usr/local/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check if the system is big endian
-- Searching 16 bit integer
-- Looking for sys/types.h
-- Looking for sys/types.h - found
-- Looking for stdint.h
-- Looking for stdint.h - found
-- Looking for stddef.h
-- Looking for stddef.h - found
-- Check size of unsigned short
-- Check size of unsigned short - done
-- Using unsigned short
-- Check if the system is big endian - little endian
-- Looking for strings.h
-- Looking for strings.h - found
-- Looking for inttypes.h
-- Looking for inttypes.h - found
-- Looking for memory.h
-- Looking for memory.h - found
-- Looking for stdlib.h
-- Looking for stdlib.h - found
-- Looking for string.h
-- Looking for string.h - found
-- Looking for sys/stat.h
-- Looking for sys/stat.h - found
-- Looking for unistd.h
-- Looking for unistd.h - found
-- Check size of ssize_t
-- Check size of ssize_t - done
-- Checking for 64-bit off_t
-- Checking for 64-bit off_t - present with _FILE_OFFSET_BITS=64
-- Checking for fseeko/ftello
-- Checking for fseeko/ftello - present
-- Large File support - found
-- Found ZLIB: /usr/lib/libz.so
-- Your system seems to have a Z lib available, we will use it to generate PNG lib
-- DEBUG: vs /usr/include
-- Found PNG: /usr/lib/libpng.so
-- Your system seems to have a PNG lib available, we will use it
-- Found TIFF: /usr/lib/libtiff.so
-- Your system seems to have a TIFF lib available, we will use it
-- Found LCMS2: /usr/local/lib/liblcms2.so
-- Your system seems to have a LCMS2 lib available, we will use it
WARNINGNo java compiler found. Wont be able to build java viewer
CMake Error: File /usr/local/share/cmake-2.6/Templates/AppleInfo.plist does not exist.
CMake Error at cmake/OpenJPEGCPack.cmake:63 (configure_file):
configure_file Problem configuring file
Call Stack (most recent call first):
CMakeLists.txt:255 (include)


-- Configuring incomplete, errors occurred!

--
Bob Friesenhahn
bfri...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/

[Mathieu Malaterre]

Bob,

On Mon, Oct 1, 2012 at 3:59 PM, Bob Friesenhahn
<bfri...@simple.dallas.tx.us> wrote:
[...]

> The "single build method" email posting made me feel very sad. There is a
> reason why portable software is using Autotools and only ported software
> uses 'cmake'. There is a significant difference between "portable" and
> "ported".

While I can certainly understand your feelings about loosing a large
projet using autotools, I would really appreciate if you could
describe facts. Spreading FUDs was once reserved to large
corporations, with specific goals in mind.

Please take into account the dev team point of view of maintaining
duplicate build system. With your background, I am sure you understand
that duplicate work and computer science do not work well together.

> This is what happens for me if I use the incantation above:

[...]

> CMake Error: File /usr/local/share/cmake-2.6/Templates/AppleInfo.plist does
> not exist.
> CMake Error at cmake/OpenJPEGCPack.cmake:63 (configure_file):
> configure_file Problem configuring file

Somewhat fixed/hacked. Which linux distro is still distributing cmake 2.6.x ?

Regards,
--
Mathieu

[Bob Friesenhahn]

On Mon, 1 Oct 2012, Mathieu Malaterre wrote:
>
>> This is what happens for me if I use the incantation above:
> [...]
>> CMake Error: File /usr/local/share/cmake-2.6/Templates/AppleInfo.plist does
>> not exist.
>> CMake Error at cmake/OpenJPEGCPack.cmake:63 (configure_file):
>> configure_file Problem configuring file
>
> Somewhat fixed/hacked. Which linux distro is still distributing cmake 2.6.x ?

I see how it was "fixed". I have no idea what Linux distributions are
still distributing cmake 2.6.x but I expect that they would be ones
with "Enterprise", "LTS", or "stable" in their descriptions. These
would be the ones most commonly encountered in service applications.

When people use package management systems, they generally go with the
cmake which is offered via their package management system.

Bob

[Julien Malik]

Hi,

On 01/10/2012 16:23, Mathieu Malaterre wrote:
> Bob,
>
> On Mon, Oct 1, 2012 at 3:59 PM, Bob Friesenhahn
> <bfri...@simple.dallas.tx.us> wrote:
> [...]
>> The "single build method" email posting made me feel very sad. There is a
>> reason why portable software is using Autotools and only ported software
>> uses 'cmake'. There is a significant difference between "portable" and
>> "ported".
> While I can certainly understand your feelings about loosing a large
> projet using autotools, I would really appreciate if you could
> describe facts. Spreading FUDs was once reserved to large
> corporations, with specific goals in mind.
>
> Please take into account the dev team point of view of maintaining
> duplicate build system. With your background, I am sure you understand
> that duplicate work and computer science do not work well together.
>

Concerning the openjpeg large file support, we have everything in place
in cmake to "make it right" on all platforms, detecting LFS at configure
time even for msvc compilers (see cmake/TestWindowsFSeek.c, and
corresponding commented code in TestLargeFiles.cmake.in).

At that time, because of the need to keep autotools working, we kept in
opj_includes.h a horrible piece of #define (thanks to Bob by the way,
because this is copy/pasted from graphicmagick implementation) :

=============
#if defined(WIN32) && !defined(Windows95) && !defined(__BORLANDC__) && \
!(defined(_MSC_VER) && _MSC_VER < 1400) && \
!(defined(__MINGW32__) && __MSVCRT_VERSION__ < 0x800)
/*
Windows '95 and Borland C do not support _lseeki64
Visual Studio does not support _fseeki64 and _ftelli64 until the
2005 release.
Without these interfaces, files over 2GB in size are not supported
for Windows.
*/
...

==============


Clearly not the best "portable" part of openjpeg ;)
To my knowledge, cmake is able to do anything autotools can do, but not
the other way around (targeting msvc, for example).

There might be a few bits missing for systems where nobody tested the
cmake build system yet.
Good thing is that, as Mathieu mentions, you can publish your build
results for such platforms on the dashboard to provide material to the
maintainers for solving those issues.

Julien

[Mathieu Malaterre]

On Mon, Oct 1, 2012 at 4:48 PM, Bob Friesenhahn
<bfri...@simple.dallas.tx.us> wrote:
> On Mon, 1 Oct 2012, Mathieu Malaterre wrote:
>> Somewhat fixed/hacked. Which linux distro is still distributing cmake
>> 2.6.x ?
>
>
> I see how it was "fixed". I have no idea what Linux distributions are still
> distributing cmake 2.6.x but I expect that they would be ones with
> "Enterprise", "LTS", or "stable" in their descriptions. These would be the
> ones most commonly encountered in service applications.

Point taken. We need to discuss which cmake version we need to target for v2.

Thanks,
--
Mathieu

[szuk...@arcor.de]

On Tue, 17 Jul 2012 04:52:52 -0500, Seg wrote:

>OpenJPEG doesn't have wide enough usage

I am sure that the usage will shrink further with
the single build method and broken MJ2 code.

winfried

[Jonathan Ballard]

Full JPEG2000 does not have wide enough usage.

Wrap the CMake files in .NET.exe.

class make {

  Main()

  {

  String make_command = "cmake" ;

  String make_file = MAKEFILE;

  // System(make_command + " " +  make_file);

  }

}

--
You are subscribed to the mailing-list of the OpenJPEG project (www.openjpeg.org)
To post: email to open...@googlegroups.com
To unsubscribe: email to openjpeg+u...@googlegroups.com
For more options: visit http://groups.google.com/group/openjpeg
For more info about OpenJPEG main partners : visit  www.tele.ucl.ac.be (UCL) and www.intopix.com

[Bob Friesenhahn]

I have gotten a further after installing latest cmake.
Unfortunately, the build fails with this error (On Solaris 10):

[ 26%] Building C object src/lib/openjpip/CMakeFiles/openjpip_local.dir/openjpip.c.o
In file included from /home/bfriesen/src/graphics/openjpeg-svn/src/lib/openjp2/opj_stdint.h:29:0,
from /home/bfriesen/src/graphics/openjpeg-svn/src/lib/openjpip/byte_manager.h:35,
from /home/bfriesen/src/graphics/openjpeg-svn/src/lib/openjpip/index_manager.h:34,
from /home/bfriesen/src/graphics/openjpeg-svn/src/lib/openjpip/target_manager.h:35,
from /home/bfriesen/src/graphics/openjpeg-svn/src/lib/openjpip/cachemodel_manager.h:35,
from /home/bfriesen/src/graphics/openjpeg-svn/src/lib/openjpip/channel_manager.h:36,
from /home/bfriesen/src/graphics/openjpeg-svn/src/lib/openjpip/session_manager.h:35,
from /home/bfriesen/src/graphics/openjpeg-svn/src/lib/openjpip/openjpip.h:34,
from /home/bfriesen/src/graphics/openjpeg-svn/src/lib/openjpip/openjpip.c:32:
/home/bfriesen/src/graphics/openjpeg-svn/src/lib/openjp2/opj_config.h:21:0: warning: "_FILE_OFFSET_BITS" redefined [enabled by default]
In file included from /usr/local/lib/gcc/i386-pc-solaris2.10/4.7.1/include-fixed/iso/stdlib_iso.h:39:0,
from /usr/include/stdlib.h:18,
from /home/bfriesen/src/graphics/openjpeg-svn/src/lib/openjpip/openjpip.c:31:
/usr/local/lib/gcc/i386-pc-solaris2.10/4.7.1/include-fixed/sys/feature_tests.h:196:0: note: this is the location of the previous definition
In file included from /home/bfriesen/src/graphics/openjpeg-svn/src/lib/openjpip/openjpip.c:32:0:
/home/bfriesen/src/graphics/openjpeg-svn/src/lib/openjpip/openjpip.h:281:23: error: conflicting types for 'index_t'
In file included from /usr/include/time.h:22:0,
from /home/bfriesen/src/graphics/openjpeg-svn/src/lib/openjpip/channel_manager.h:34,
from /home/bfriesen/src/graphics/openjpeg-svn/src/lib/openjpip/session_manager.h:35,
from /home/bfriesen/src/graphics/openjpeg-svn/src/lib/openjpip/openjpip.h:34,
from /home/bfriesen/src/graphics/openjpeg-svn/src/lib/openjpip/openjpip.c:32:
/usr/include/sys/types.h:109:16: note: previous declaration of 'index_t' was here
gmake[2]: *** [src/lib/openjpip/CMakeFiles/openjpip_local.dir/openjpip.c.o] Error 1
gmake[1]: *** [src/lib/openjpip/CMakeFiles/openjpip_local.dir/all] Error 2
gmake: *** [all] Error 2

It seems that src/lib/openjpip/openjpip.h uses:

typedef index_param_t index_t;

which conflicts with this from /usr/include/sys/types.h :

typedef short index_t;


I encounter the same problem under OpenIndiana 151a5.


Then I attempted a compile on another common system (FreeBSD 8) and
encountered a different failure:

[ 0%] Building C object src/lib/openjp2/CMakeFiles/openjp2.dir/bio.c.o
In file included from /home/bfriesen/src/graphics/openjpeg-svn/src/lib/openjp2/opj_malloc.h:89,
from /home/bfriesen/src/graphics/openjpeg-svn/src/lib/openjp2/opj_includes.h:150,
from /home/bfriesen/src/graphics/openjpeg-svn/src/lib/openjp2/bio.c:32:
/usr/include/malloc.h:3:2: error: #error "<malloc.h> has been replaced by <stdlib.h>"
gmake[2]: *** [src/lib/openjp2/CMakeFiles/openjp2.dir/bio.c.o] Error 1
gmake[1]: *** [src/lib/openjp2/CMakeFiles/openjp2.dir/all] Error 2
gmake: *** [all] Error 2

On this system it did not even manage to compile a single file.

Bob