Project

General

Profile

Patch #1119

libxmp missing from the install folder when building statically libexiv2

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

Status:
Closed
Priority:
Normal
Assignee:
Category:
build
Target version:
Start date:
23 Sep 2015
Due date:
% Done:

100%

Estimated time:
3.00 h

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


Files

libxmp-copy-to-install-shared-off.patch (550 Bytes) libxmp-copy-to-install-shared-off.patch Emmanuel d'Angelo, 23 Sep 2015 07:40
Rafa.jpg (270 KB) Rafa.jpg Robin Mills, 23 Sep 2015 08:15

Related issues

Related to Exiv2 - Feature #1041: CMake toolchain for windowsClosed15 Mar 2015

Actions

Associated revisions

Revision 3961 (diff)
Added by Robin Mills about 6 years ago

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

History

#1

Updated by Robin Mills about 6 years ago

I will not work on CMake issues.

#2

Updated by Emmanuel d'Angelo about 6 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 6 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 6 years ago

Enjoy your walk :-)

#5

Updated by Robin Mills about 6 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 6 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 6 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 6 years ago

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

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 about 6 years ago

  • Status changed from Resolved to Closed
#10

Updated by Wolfgang Bauer almost 3 years ago

Robin Mills wrote:

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.

Unfortunately, installing a static lib is not really acceptable for some Linux distributions, openSUSE in particular.

It was not a problem for us in 0.26, as we just deleted libxmp.a, so sorry for not reporting that earlier.

But now in 0.27.0, the new exiv2Config.cmake refers to that file, and not having it installed breaks other packages that try to use that via cmake...
I probably should open a new issue about that (right?), but I thought I should mention it here anyway.

See https://api.opensuse.org/request/show/662725 for the discussion. (I hope that can be read without logging in...)

#11

Updated by Robin Mills almost 3 years ago

Best Wishes for 2019. We try to make life easier, and it gets harder!

Can I ask you to report this as an issue on http://github.com/exiv2/exiv2. Last we agreed to change the name of that library.

When you report this could you explain a little more about installing a static lib is not really acceptable for some Linux distributions, openSUSE in particular. Are you saying that we should be building a shared library, or do you have another suggestion?

As you can see, I read and service issues reported on Redmine. With the release of v0.27, I wanted to make Redmine read-only and haven't found a way to do that.

#12

Updated by Wolfgang Bauer almost 3 years ago

Robin Mills wrote:

Best Wishes for 2019.

Best wishes for you as well!

Can I ask you to report this as an issue on http://github.com/exiv2/exiv2. Last we agreed to change the name of that library.

Of course, I will do tomorrow...

Sorry, didn't know about the change.

And don't worry, it's just some detail we apparently need to sort out somehow. (and definitely will, in one way or the other, I'm sure. ;-) )

#13

Updated by Robin Mills almost 3 years ago

We'll sort it out. We always do.

There's no way for you to know that I want Redmine to be read-only. I've hunted through all the settings and can't find a way. I could go to the server and change some permissions in the file system. At worst Redmine could crash. Even worse: Redmine pretends that everything is OK. Software? It's an invisible enemy!

Also available in: Atom PDF