Legacy ImageMagick Discussions Archive • Installing delegate FlashPIX (libpfx) fails in Debian/Ubuntu

Page 1 of 1

Installing delegate FlashPIX (libpfx) fails in Debian/Ubuntu

Posted: 2014-03-04T05:30:53-07:00

by Antonio19

6 month ago I started a new topic "Installing delegate (libfpx) on Ubuntu 12.04 fails" @ viewtopic.php?f=1&t=24126 seeking help on how to build ImageMagick in order to support this delegate format. I got no valid answer. An admin of the site stated "As a sanity check, we compiled / installed FlashPix 1.3.1-3 and then configured and compiled ImageMagick 6.8.6-10 [on Fedora]. The configure script found the FlashPix library and linked it without complaint."

Then 1 month later in same thread another one complained about the same thing for his build on an a [Debian] Ubuntu Server. No intelligible response from the admin team.

Though a rule of thumb in the software business is that if 2 different users got the same bug then there is a likely 100 % chance the bug is for real ... That is not an enforced rule here at ImageMagick.

I then revisited the issue over the last week-end and was ready to investigate further as no other would even look at it seriously. I found the bug in the configure script and made a patch. I posted my findings on my thread. The following day some one from ImageMagick told me to post this in the bugs section of the forum. So here I am. I will only post here my latest post detailing the solution. All the postings are available on the thread identified earlier.

From the config.log file hopefully I got the C++ file conftest.cpp and got the compilation CLI which failed :

Code: Select all

$ g++ -o conftest -O3 -g3 -pthread -DMAGICKCORE_HDRI_ENABLE=1 -DMAGICKCORE_QUANTUM_DEPTH=16 conftest.cpp -lfpx -lfftw3 -ldjvulibre -lz -lXext -lXt -lSM -lICE -lX11 -lbz2 -lgomp -lm    >&5

After searching for a while on g++ linking shared libraries, I decided to run the compilation command line with no other linked libraries than libfpx:

Code: Select all

$ g++ -o conftest -O3 -g3 -pthread -DMAGICKCORE_HDRI_ENABLE=1 -DMAGICKCORE_QUANTUM_DEPTH=16 conftest.cpp -lfpx

It compiled without errors. Then I tried to look for which linked shared libraries the error popped. That was the libdjvulibre library ... Removing the -ldjvulibre from the command line had the conftest.cpp compiled again without errors:

Code: Select all

$ g++ -o conftest -O3 -g3 -pthread -DMAGICKCORE_HDRI_ENABLE=1 -DMAGICKCORE_QUANTUM_DEPTH=16 conftest.cpp -lfpx -lfftw3 -lz -lXext -lXt -lSM -lICE -lX11 -lbz2 -lgomp -lm

gave me an object file conftest (as specified in the command).

I did check on the package implementing this djvulibre shared library : It's the Official Ubuntu package for Raring 13.04: Package name is libdjvulibre21 and version is 3.5.25.3-3 .

Obviouly then this is a bug in the ImageMagick configure script present in the source tarball.

As I believe that the ImageMagick team will take years to correct this bug, I went on to correct this one myself in order to have a build supporting this format. So here are my findings and the patch to the configure script for the latest version 6.8.8-7. The nbr: on the left is the line nbr of that file.

Code: Select all

28740:    LIBS="$DJVU_LIBS $LIBS"      --->   is adding -ldjvulibre to the set of linked libraries.

This set of linked libraries is then used with the compilation CLI of later delegates (I don't know why exactly ...).

Code: Select all

28938:    ac_check_lib_save_LIBS=$LIBS     --->  saving the value of LIBS before adding -lfpx to LIBS
    28939:    LIBS="-lfpx  $LIBS"             --->  is adding -lfpx to the linker.

My working patch and proposed change is to add a line after 28939: . The new line will be hence 28940:

28940: LIBS=${LIBS/-ldjvulibre/} ---> This will remove the djvulibre library from the linker

This has no incidence on the other delegates as LIBS is restored to its saved value on the following line

Code: Select all

28966:    LIBS=$ac_check_lib_save_LIBS   ---> This is restoring the value of LIBS to its earlier saved value

Before leaving the code implementing FlashPIX support.

This command performed after installation of the new build

Code: Select all

$ identify -list format
    [...]
          FPX  rw-   FlashPix Format
    [...]

confirms full support for the FlashPIX FPX Format.

The configure script was to blame for the error. Will you take any action to correct this behaviour?

I went on to look at other unsupported format in my build. I found that LIBOPENJP2 was not supported although I have version 1.3, 1.5 and 2.0 installed. This is corresponding to so version 2, 5 and 6. The sources are coming from OpenJPEG at http://www.openjpeg.org/ and http://code.google.com/p/openjpeg. Your script is looking for a package named "libopenjp2" ... At least on all Debian Linux there has never been any package of this name ... The related packages are named (according to the developers group name) libopenjpeg2 (for shared library libopenjpeg.so.2), libopenjpeg5 (for shared library libopenjpeg.so.5) and libopenjpeg6 (for shared library libopenjpeg.so.6) ...

It looks like we are far away from any standard JPEG 2000 (from OpenJPEG) recognition in ImageMagicks.

Thanks for taking time to read this post.

Re: Installing delegate FlashPIX (libpfx) fails in Debian/Ub

Posted: 2014-03-04T06:01:47-07:00

by magick

The configure script is a generated file, output from the autoconf command. Any patches must be applied to configure.ac. Can you review configure.ac and post a patch here. We do not have access to Debian to test our patches or we would add a patch ourselves.

Regarding JPEG 2000 support. We held off supporting OpenJPEG because its API was deficient. However, the very latest OpenJPEG 2 met our requirements. In the latest OpenJPEG 2 they renamed their library from openjpeg to openjp2. For now, its likely you would need to build OpenJPEG from the git or subversion repository until the Linux distributions update to the very latest release of OpenJPEG.

Re: Installing delegate FlashPIX (libpfx) fails in Debian/Ub

Posted: 2014-03-04T13:48:08-07:00

by Antonio19

OK. You had a good call about the configure script which is automatically generated by GNU autoconf. I looked carefully at how the configure.ac was laid out. The build of the command line to compile the conftest.cpp with the linked libraries for libfpx is the following:

Code: Select all

1938:    AC_CHECK_LIB(fpx,FPX_OpenImageByFilename,passed=`expr $passed + 1`,failed=`expr $failed + 1`,)

When the test compile is considered passed you perform the block of code between lines [1945 : 1951]

Code: Select all

        else
            FPX_LIBS='-lfpx'
            AC_DEFINE(FPX_DELEGATE,1,Define if you have FlashPIX library)
            AC_MSG_RESULT([yes])
            have_fpx='yes'
            PERLMAINCC="$CXX"
        fi

Note that you do not add the libfpx library to the set of linked libraries to used for further delegates libraries testing.

For the libdjvulibre library you have the following line and block of code between lines [1840 : 1846]

Code: Select all

1834:    AC_CHECK_LIB(djvulibre,ddjvu_context_create,passed=`expr $passed + 1`,failed=`expr $failed + 1`,)
[...]
        else
            DJVU_LIBS='-ldjvulibre'
            LIBS="$DJVU_LIBS $LIBS"
            AC_DEFINE(DJVU_DELEGATE,1,Define if you have DJVU library)
            AC_MSG_RESULT([yes])
            have_djvu='yes'
        fi

Note that here you add the libdjvulibre library to the set of linked libraries to used for further delegates libraries testing.

I had a look at the definition of GNU Macro: AC_CHECK_LIB @ http://www.gnu.org/savannah-checkouts/g ... aries.html

Code: Select all

AC_CHECK_LIB (library, function, [action-if-found], [action-if-not-found], [other-libraries])

action-if-found is a list of shell commands to run if the link with the library succeeds; action-if-not-found is a list of shell commands to run if the link fails. If action-if-found is not specified, the default action prepends -llibrary to LIBS and defines ‘HAVE_LIBlibrary’ (in all capitals). This macro is intended to support building LIBS in a right-to-left (least-dependent to most-dependent) fashion such that library dependencies are satisfied as a natural side effect of consecutive tests. Linkers are sensitive to library ordering so the order in which LIBS is generated is important to reliable detection of libraries.

LIBS which is the set of linked libraries we talked about before is directly used by this GNU Macro. There is no way to patch here. For some reasons you decided to add the libdjvulibre library to this set of libraries LIBS with the line LIBS="$DJVU_LIBS $LIBS". Then the only way to get a successful compilation of libfpx is to invoke AC_CHECK_LIB before you invoke it for libdjvulibre.

This requires moving the entire block of code line [1912 : 1958] which is:

Code: Select all

dnl ===========================================================================

#
# Check for FlashPIX delegate library.
#
AC_ARG_WITH([fpx],
    [AC_HELP_STRING([--without-fpx],
                    [disable FlashPIX support])],
    [with_fpx=$withval],
    [with_fpx='yes'])

if test "$with_fpx" != 'yes'; then
    DISTCHECK_CONFIG_FLAGS="${DISTCHECK_CONFIG_FLAGS} --with-fpx=$with_fpx "
fi

have_fpx='no'
FPX_LIBS=''
if test "$with_fpx" != 'no'; then
    AC_MSG_RESULT([-------------------------------------------------------------])
    AC_MSG_CHECKING([for FlashPIX])
    AC_MSG_RESULT([])
    failed=0
    passed=0
    AC_LANG_PUSH(C++)
    AC_CHECK_HEADER(fpxlib.h,passed=`expr $passed + 1`,failed=`expr $failed + 1`)
    AC_CHECK_LIB(fpx,FPX_OpenImageByFilename,passed=`expr $passed + 1`,failed=`expr $failed + 1`,)
    AC_LANG_POP
    AC_MSG_CHECKING([if FlashPIX package is complete])
    if test $passed -gt 0; then
        if test $failed -gt 0; then
            AC_MSG_RESULT([no -- some components failed test])
            have_fpx='no (failed tests)'
        else
            FPX_LIBS='-lfpx'
            AC_DEFINE(FPX_DELEGATE,1,Define if you have FlashPIX library)
            AC_MSG_RESULT([yes])
            have_fpx='yes'
            PERLMAINCC="$CXX"
        fi
    else
        AC_MSG_RESULT([no])
    fi
fi
AM_CONDITIONAL(FPX_DELEGATE, test "$have_fpx" = 'yes')
AC_SUBST(FPX_LIBS)

before the block of code lines for libdjvulibre starting at line 1812.

[EDIT]: I had a second thought about the proposed patch. This will stick closer to the patch I used on the configure script and will not require to move a block of code in the configure.ac file.

Within the code portion for testing libfpx I can still use the line LIBS=${LIBS/-ldjvulibre/} which will remove any occurence of libdjvulibre before the call to AC_CHECK_LIB, but I need right before modifying LIBS to save its value in a new variable like SAVED_LIBS and at the end of the code block for testing libfpx I need to restore the value of LIBS from SAVED_LIBS . Here we need to add 3 lines in the block of code for testing libfpx.

After line 1929: FPX_LIBS='' I will add 2 lines:

Code: Select all

1929:    FPX_LIBS=''
1930:    SAVED_LIBS=${LIBS}
1931:    LIBS=${LIBS/-ldjvulibre/}

And after what is now line 1959: AC_SUBST(FPX_LIBS) I will add 1 line:

Code: Select all

1959:    AC_SUBST(FPX_LIBS)
1960:    LIBS=${SAVED_LIBS}

I did test the 2 solutions I propose here with modified configure.ac files and it worked out well on my Debian / Ubuntu platform in both cases. In a word the place of any new delegates relative to the others you chose to add in the set of linked libraries has a detrimental effect on how successful or not the test might be. But to be able to place the code portion anywhere in configure.ac , it is better to use the insertion of 3 code lines within the affected delegate (libfpx).

I hope you will agree on the proposed changes ?

Regarding your comments on OpenJPEG, I strongly disagree with you. Their own website http://www.openjpeg.org/index.php?menu=download or http://code.google.com/p/openjpeg/downloads/list never use the word libopenjp2. They do not provide any linux libraries, they only provide the source, which is logical. When compiling this source code we get for version 1.3+dfsg a library named libopenjpeg-2.1.3.0 and for version 1.5 we get libopenjpeg.so.1.5.0 . Debian considers the 1.3+dfsg version as stable while the 1.5 version is in unstable sid and 2.0 (which I have compiled) is for me still incomplete for the java and jpip server parts. Another difference is the names of the binaries which are the same for version 1.3 and 1.5 e.g. image_to_j2k, j2k_to_image, etc... vs. for version 2.0 opj_compress, opj_decompress, etc...

As a matter of fact, the Red Hat distribution has chosen the name of libopenjp2 for these libraries. This is only valid for RPM packages & distributions and does not reflect the work (on names) of the developers. By the way, at the moment I don't have any RPM distro installed in my systems.

Re: Installing delegate FlashPIX (libpfx) fails in Debian/Ub

Posted: 2014-03-04T14:09:51-07:00

by magick

Would it be sufficient to add

LIBS="$FPX_LIBS $LIBS"

around configure.ac/1947?

We're using OpenJPEG from the Subversion trunk:

svn checkout http://openjpeg.googlecode.com/svn/trunk/ openjpeg

which returns:

Installing: /usr/local/lib/libopenjp2.so.2.0.0

Typically we prefer to use released code, however we found the openjpeg-2.0.0 release problematic when we first tried it last year. The OpenJPEG trunk has a much improved API.

Re: Installing delegate FlashPIX (libpfx) fails in Debian/Ub

Posted: 2014-03-04T14:58:40-07:00

by Antonio19

Well, no you can't add LIBS="$FPX_LIBS $LIBS" around line 1947 of configure.ac . This will not work because you would have already called AC_CHECK_LIB with the variable LIBS containing -ldjvulibre ... That will return a fail result.

I edited my answer while you were posting your message.

I think the better way to do it is the insertion of 3 code lines, whithout moving aything around and that will be within the affected delegate. See the [EDIT]: portion on the bottom half of my post.

Thank you for the link of OpenJPEG svn I will definitely try a build from it.

Re: Installing delegate FlashPIX (libpfx) fails in Debian/Ub

Posted: 2014-03-04T17:24:03-07:00

by magick

Your patch will be in the ImageMagick subversion trunk within the hour. Thanks.

Re: Installing delegate FlashPIX (libpfx) fails in Debian/Ub

Posted: 2014-08-05T23:44:35-07:00

by electricart

Hello there. I've been following this bug and a number of releases have happened since this was apparently added to the trunk. Is this now fixed?

We're trying to compile Imagemagick 6.8.9-6 on Ubuntu 12.04 LTS and still can't get FlashPIX to be recognised. Performing configure results in;

Code: Select all

-------------------------------------------------------------
checking for FlashPIX... 
checking fpxlib.h usability... yes
checking fpxlib.h presence... yes
checking for fpxlib.h... yes
checking for FPX_OpenImageByFilename in -lfpx... no
checking if FlashPIX package is complete... no -- some components failed test
-------------------------------------------------------------

FlashPIX has been compiled and installed and is present.

The config log shows;

Code: Select all

configure:28990: checking for FlashPIX
configure:28992: result: 
configure:29003: checking fpxlib.h usability
configure:29003: g++ -c -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -pthread  -D_FORTIFY_SOURCE=2 -DMAGICKCORE_HDRI_ENABLE=0 -DMAGICKCORE_QUANTUM_DEPTH=16  -I/usr/include/X11 conftest.cpp >&5
configure:29003: $? = 0
configure:29003: result: yes
configure:29003: checking fpxlib.h presence
configure:29003: g++ -E  -D_FORTIFY_SOURCE=2 -DMAGICKCORE_HDRI_ENABLE=0 -DMAGICKCORE_QUANTUM_DEPTH=16  -I/usr/include/X11 conftest.cpp
configure:29003: $? = 0
configure:29003: result: yes
configure:29003: checking for fpxlib.h
configure:29003: result: yes
configure:29011: checking for FPX_OpenImageByFilename in -lfpx
configure:29036: g++ -o conftest -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -pthread  -D_FORTIFY_SOURCE=2 -DMAGICKCORE_HDRI_ENABLE=0 -DMAGICKCORE_QUANTUM_DEPTH=16  -I/usr/include/X11 -Wl,-Bsymbolic-functions -Wl,-z,relro  -L/usr/lib/X11 conftest.cpp -lfpx  -lfftw3 -ldjvulibre -lltdl -lz -lXext -lXt  -lSM -lICE -lX11  -lbz2 -lgomp -lrt -lm    >&5
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib/libfpx.so: undefined reference to `operator delete(void*)'
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib/libfpx.so: undefined reference to `operator new[](unsigned long)'
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib/libfpx.so: undefined reference to `atan2'
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib/libfpx.so: undefined reference to `std::ios_base::Init::~Init()'
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib/libfpx.so: undefined reference to `__cxa_pure_virtual'
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib/libfpx.so: undefined reference to `operator delete[](void*)'
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib/libfpx.so: undefined reference to `__gxx_personality_v0'
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib/libfpx.so: undefined reference to `std::ios_base::Init::Init()'
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib/libfpx.so: undefined reference to `vtable for __cxxabiv1::__si_class_type_info'
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib/libfpx.so: undefined reference to `pow'
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib/libfpx.so: undefined reference to `operator new(unsigned long)'
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib/libfpx.so: undefined reference to `sqrt'
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib/libfpx.so: undefined reference to `sincosf'
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib/libfpx.so: undefined reference to `vtable for __cxxabiv1::__class_type_info'
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib/libfpx.so: undefined reference to `vtable for __cxxabiv1::__vmi_class_type_info'
collect2: ld returned 1 exit status

Ubuntu version;

Code: Select all

$ cat /etc/*-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=12.04
DISTRIB_CODENAME=precise
DISTRIB_DESCRIPTION="Ubuntu 12.04.5 LTS"
NAME="Ubuntu"
VERSION="12.04.5 LTS, Precise Pangolin"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu precise (12.04.5 LTS)"
VERSION_ID="12.04"

Looks like the problem is still there? Any help on this would be greatly appreciated. We'd love to finally be able to have FlashPIX support if possible...

Thanks all for your work on this Antonio.

Re: Installing delegate FlashPIX (libpfx) fails in Debian/Ub

Posted: 2014-08-06T03:19:37-07:00

by magick

Take a look at config.log. It will tell you precisely why the FlashPix delegate library failed to validate. Fix the problem and rerun the configure script until the validation is successful.

Re: Installing delegate FlashPIX (libpfx) fails in Debian/Ub

Posted: 2014-08-06T17:53:23-07:00

by electricart

Take a look at config.log. It will tell you precisely why the FlashPix delegate library failed to validate. Fix the problem and rerun the configure script until the validation is successful.

Hi, thanks for your response. However honestly that's not very helpful. I *have* looked at the config.log - and I have exactly the same error that occured before the bug, and the same error that Antonio received as well - basically my config.log reads the same as the reported bug - i.e. maybe it's not fixed? Was Antonio's patch applied? According to the release notes it looks like it was, however I'm still getting the same error - and hence my post?

If you read this thread, and the one preceding it you will see that this is the case;

viewtopic.php?f=1&t=24126

Re: Installing delegate FlashPIX (libpfx) fails in Debian/Ub

Posted: 2014-08-06T19:23:34-07:00

by electricart

I just checked the config.ac file and it appears Antonio's patch has not been applied. When do you think that his implementation may be accepted and added into a release?

Re: Installing delegate FlashPIX (libpfx) fails in Debian/Ub

Posted: 2014-08-07T05:14:45-07:00

by magick

Apparently we applied the patch to ImageMagick version 7, but not version 6. We'll get the patch into 6.8.9-7 Beta, a release is not expected until the end of the month, although it could happen sooner.

Re: Installing delegate FlashPIX (libpfx) fails in Debian/Ub

Posted: 2014-08-12T00:23:47-07:00

by electricart

Ok, thanks so much for following this up. We'll wait for the new release.