OSX build gives libopenjp2.6.dylib with not-absolute install name id

[GoogleCodeExporter]

What steps will reproduce the problem?

1. Download openjpeg-2.0.0.tar.gz
2. tar zxvf openjpeg-2.0.0.tar.gz && cd openjpeg-2.0.0
3. cmake .  && make
4. DESTDIR=/Users/mb312/tmp/junk make install
5. otool -D /Users/mb312/tmp/junk/usr/local/lib/libopenjp2.2.0.0.dylib

What is the expected output? What do you see instead?

The command above gives the 'install_name_id'.  This generally gives the path 
location of the library for other libraries to link against.  For example here 
is the output of ``otool -L /usr/local/lib/libjpeg.dylib ``:

    /usr/local/lib/libjpeg.dylib:
    /usr/local/lib/libjpeg.8.dylib (compatibility version 13.0.0, current version 13.0.0)

So, for the command (5) above, I expect to see this:

    /Users/mb312/tmp/junk/usr/local/lib/libopenjp2.2.0.0.dylib:
        /Users/mb312/tmp/junk/usr/local/lib/libopenjp2.6.dylib (compatibility version 6.0.0, current version 2.0.0)

but in fact I see:

    /Users/mb312/tmp/junk/usr/local/lib/libopenjp2.2.0.0.dylib:
    libopenjp2.6.dylib (compatibility version 6.0.0, current version 2.0.0)

Notice the library filename rather than the library path as the 
'install_name_id'. Code linking against this library will put this path into to 
a generated dynamic library as the path at which to find the library at 
run-time, and therefore the openjpeg library will either have to be in the 
current directory of the running process or will not be found at run-time.

I notice that the install_name_id is correctly set before 'make install'  Here 
``otool -D  bin/libopenjp2.6.dylib``: 

   bin/libopenjp2.6.dylib:
   /Users/mb312/tmp/openjpeg/openjpeg-2.0.0/bin/libopenjp2.6.dylib

What version of the product are you using? On what operating system?

OpenJPEG 2.0.0 on OSX 10.9.3

Please provide any additional information below.

Original issue reported on code.google.com by matthew....@gmail.com on 30 Jun 2014 at 10:53

[GoogleCodeExporter]

This seems to be a long-standing deficiency in cmake: libtool automatically 
sets the install_name correctly based on the prefix defined at compile-time, 
but instead authors have to manually insert some boilerplate/magic for 
INSTALL_NAME_DIR in some CMakeLists.txt or .cmake file

Original comment by dma...@gmail.com on 29 Aug 2014 at 3:56

[GoogleCodeExporter]

2.1.0 is the same (though it's libopenjp2.7.dylib not 2.6), and it's also the 
same problematic result in the prebuilt binary download 
(openjpeg-2.1.0-Darwin-i386.tar.gz)

Original comment by dma...@gmail.com on 29 Aug 2014 at 4:05

[GoogleCodeExporter]

Reproduced on my side.
I will provide a patch for this.

BTW, you shouldn't see /Users/mb312/tmp/junk/usr/local/lib/libopenjp2.6.dylib 
but
/usr/local/lib/libopenjp2.6.dylib.
DESTDIR is only used as a staging directory. if you want to change the prefix, 
you shall set CMAKE_INSTALL_PREFIX when configuring your build.

Original comment by m.darb...@gmail.com on 18 Sep 2014 at 9:24

• Changed state: Accepted

[GoogleCodeExporter]

Original comment by m.darb...@gmail.com on 18 Sep 2014 at 9:24

[GoogleCodeExporter]

Provided patch shows the following output :
make

otool -D ./bin/libopenjp2.dylib 
./bin/libopenjp2.dylib:
/Users/Matt/Dev/OpenJpeg/issue367/build/bin/libopenjp2.7.dylib

otool -L ./bin/opj_compress 
./bin/opj_compress:
    /Users/Matt/Dev/OpenJpeg/issue367/build/bin/libopenjp2.7.dylib (compatibility version 7.0.0, current version 2.1.0)
    /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)

DESTDIR=/Users/Matt/Dev/OpenJpeg/issue367/build/bin/install make install

otool -D ./bin/install/usr/local/lib/libopenjp2.dylib 
./bin/install/usr/local/lib/libopenjp2.dylib:
/usr/local/lib/libopenjp2.7.dylib

otool -L ./bin/install/usr/local/bin/opj_compress 
./bin/install/usr/local/bin/opj_compress:
    /usr/local/lib/libopenjp2.7.dylib (compatibility version 7.0.0, current version 2.1.0)
    /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)

The patch only affects APPLE builds
Tested against test suite & report in CDash

Original comment by m.darb...@gmail.com on 18 Sep 2014 at 9:02

• Changed state: Verified

Attachments:

• issue367.patch

[GoogleCodeExporter]

This issue was closed by revision r2882.

Original comment by antonin on 19 Sep 2014 at 9:30

• Changed state: Fixed