Patch #1119

libxmp missing from the install folder when building statically libexiv2

Added by Emmanuel d'Angelo about 2 years ago. Updated almost 2 years ago.

Status:ClosedStart date:23 Sep 2015
Priority:NormalDue date:
Assignee:Robin Mills% Done:

100%

Category:buildEstimated time:3.00 hours
Target version:0.26

Description

We build and use libexiv2 with the following workflow (linux + windows):

  1. download a clean copy of a given svn revision
  2. configure a cmake build targeting a temporary install folder
  3. build and install (from our build.bat/build.sh script)
  4. copy the content of install_folder/lib/ into our dependency lib folder.

While this workflow works well when building libexiv2 as a dynamic library, it fails when building it statically (the symbols from XMPSDK are undefined in the output static library).
There are 2 ways to solve this issue:

  • either by tweaking the cmake build to disable building a separate libxmp when building statically:
    cmake -DEXIV2_ENABLE_SHARED=OFF -DEXIV2_ENABLE_XMP=ON -DEXIV2_ENABLE_LIBXMP=OFF ...
    
  • or by copying libxmp.a to the install folder, which is performed by the attached patch.

Best regards,

Emmanuel

libxmp-copy-to-install-shared-off.patch Magnifier (550 Bytes) Emmanuel d'Angelo, 23 Sep 2015 07:40

Rafa.jpg (270 KB) Robin Mills, 23 Sep 2015 08:15


Related issues

Related to Exiv2 - Feature #1041: CMake toolchain for windows Closed 15 Mar 2015

Associated revisions

Revision 3961
Added by Robin Mills about 2 years ago

#1119. Thank You, Emmanuel for your help and patch.

History

#1 Updated by Robin Mills about 2 years ago

I will not work on CMake issues.

#2 Updated by Emmanuel d'Angelo about 2 years ago

Fine for me. The patch is here in case you want to propagate the fix to other users of the library (or hope that google will help users getting this issue too in finding this ticket). In our case, we updated our build scripts to use solution number 1.

#3 Updated by Robin Mills about 2 years ago

Thank You, Emmanuel.

I'm very frustrated by CMake/Visual Studio. I've spent a lot of time on it and it's still not working very well. You'll have seen that TModes wants me to revert your patch from last week. I'm sure CMake/Visual Studio works OK once you understand it. I don't understand it.

I'm also very frustrated by Visual Studio 2013 and 2015. I spent 12 hours yesterday trying to get the wretched thing to install correctly on Windows/7. Total frustration.

Time for me to take the dog for a run and calm down.

#4 Updated by Emmanuel d'Angelo about 2 years ago

Enjoy your walk :-)

#5 Updated by Robin Mills about 2 years ago

  • Status changed from New to Assigned
  • Assignee set to Robin Mills
  • Target version set to 0.26

Thanks. I've calmed down now. Thanks for being nice.

This is an interesting find. The Exiv2/Visual Studio policy is to build "all dlls, or all static" and not to mix them. However, xmpsdk.a is different. It's always built as a static library and linked into libexiv2. I'm surprised that it hasn't been copied and linked correctly.

I know Daniel made changes relating to the copying. Perhaps something was disturbed. However, Daniel's an excellent engineer and I am not blaming him. I will investigate the issue.

I need to invest more time in the buildServer's CMake support to find those issues.

#6 Updated by Emmanuel d'Angelo about 2 years ago

Well, it took me quite some time to realize what was happening, especially since I could see that the xmpsdk files were built correctly and the dynamic lib build was all right.

My guess: when building a dynamic lib it's not noticeable, because the final dynamic library will be linked with the (always static) libxmp, and so it copies the symbols and the code at link time. This link time copy phase does not take place when everything is built statically. You don't notice this either when building the executable exiv2 because the cmake settings are still valid. In our case (using libexiv2 without using exiv2), then the symbols are missing.

Note that in my patch I only uncomment a line that was already there. Perhaps it was gone at some point because its effects could not be observed (see above). Anyway, I don't blame anyone either, we have a working setup on our side, we know where our build errors come from (and how to fix them), and I've reported back to the project any issue that I had to solve :-)

#7 Updated by Robin Mills about 2 years ago

Fix submitted r3961 It's not identical to your patch, as I will explain.

I commented off that INSTALL in June 2012. That was when most of the CMake/Visual Studio work was done while I was between contracts. I think the INSTALL was removed because it usually requires sudo privileges. However, you're right. The shared library and executables are happy. However your application needs to link the installed libxml symbols.

When we do a sudo make install, we should install libxmp.a in /usr/local/lib. I messed with the code, and concluded that your code is correct. It should go into xmpsdk/CMakeLists.txt. I'm not going to restrict it to the static build:

    # 1119  Install libxmp.a for use by third party applications (Thanks, Emmanuel)
    INSTALL(TARGETS xmp ${INSTALL_TARGET_STANDARD_ARGS} )
So, the main part of xmpsdk/CMakeLists.txt is now:
    23    IF( EXIV2_ENABLE_XMP AND EXIV2_ENABLE_LIBXMP )
    24        ADD_LIBRARY( xmp STATIC ${XMPSRC} )
    25        GET_TARGET_PROPERTY( XMPLIB xmp LOCATION )
    26        TARGET_LINK_LIBRARIES(xmp ${EXPAT_LIBRARIES})
    27        # 1119  Install libxmp.a for use by third party applications (Thanks, Emmanuel)
    28        INSTALL(TARGETS xmp ${INSTALL_TARGET_STANDARD_ARGS} )
    29    ENDIF()

#8 Updated by Robin Mills about 2 years ago

  • Status changed from Assigned to Resolved
  • % Done changed from 0 to 100
  • Estimated time set to 3.00

I'm going to mark this as "Resolved/100%". That means that I don't expect to do further work on this matter. If nothing else arises relating to this issue, it'll be closed before we ship v0.26.

#9 Updated by Robin Mills almost 2 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF

Redmine Appliance - Powered by TurnKey Linux