Exiv2

That's bad. I'll check over the weekend.

Nope, I can't reproduce that. Phew!!

Compiled 0.25 with ./configure; make; make install and all looks and works as it should:

1. The ./configure summary output includes the line Use symbol visibility support.. YES
2. Compilation commands (make output) start with libtool: compile: g++ -O2 -fvisibility=hidden -fvisibility-inlines-hidden
3. nm -C /usr/local/lib/libexiv2.so.14.0.0 shows XMP-SDK symbols as local (lowercase t), not external (T)
4. I can write a program that (re-)defines an XMP-SDK symbol (XMP_Node) and it compiles, links with libexiv2.so and runs fine

Where in the above points do you see differences on your system?

-ahu.

Hmm, strange. I just checked and indeed nm shows the symbols as defined locally only. When I use cmake instead of automake, they are shown as exported globally however.

I was sure I had the same issue with automake as well earlier. However, I did switch a couple of times between cmake/automake - maybe I mixed-up the installed version and the problem is indeed only with cmake.

Will test some more and try to reproduce. Apologies for creating work should I indeed have mixed-up the different versions.

When using cmake that's definitely a problem though (although I understand that cmake is still experimental for exiv2).

Thanks for verifying so quickly!

Yes, it's still a bug, even if it only happens when building with cmake.

-ahu.

Andreas,

With cmake there are rules to make public or private API at linking time through target_link_libraries() call.

This is an exemple taken from libkexiv2 :

https://projects.kde.org/projects/kde/kdegraphics/libs/libkexiv2/repository/revisions/frameworks/entry/src/CMakeLists.txt#L64

Here you can see that we make Exiv2 API hidden from client application. The goal is to open only libkexiv2 API. Exiv2 API will be never visible from client application.

Gilles Caulier

Andreas,

In digiKam ported to Qt5, i moved DNGConverter code from a kipi plugins to digiKAm core.

On some computer (not mine), developers has serious crash at startup. As DNGConverter use Adobe XMP sdk implementation, the loader mix both SDK between Exiv2 and digiKAm core. This crash application violently :

(gdb) bt
#0 0x00007ffff78dad39 in WXMPMeta_RegisterNamespace_1 (namespaceURI=0x7fffe5a60d48 "http://www.digikam.org/ns/1.0/", suggestedPrefix=0x7fffe5a54144 "digiKam",
registeredPrefix=0x7fffffffd740, prefixSize=0x7fffe834cb20 <main_arena>, wResult=0x3)
at /home/tootis/projects/dk/core/libs/3rdparty/dngwriter/extra/xmp_sdk/XMPCore/WXMPMeta.cpp:222
#1 0x00007fffe59d3994 in TXMPMeta<std::string>::RegisterNamespace(char const*, char const*) () from /usr/lib/libexiv2.so.13
#2 0x00007fffe59ce2f6 in Exiv2::XmpParser::initialize(void ()(void, bool), void*) () from /usr/lib/libexiv2.so.13
#3 0x00007ffff5caaa6f in KExiv2Iface::KExiv2::initializeExiv2 () at /home/tootis/projects/dk/extra/libkexiv2/src/kexiv2.cpp:80
#4 0x0000000000406bf1 in main (argc=1, argv=0x7fffffffe1f8) at /home/tootis/projects/dk/core/app/main/main.cpp:101

We have tried a lots of changes to fix the problem, as to use different Exiv2 version including 0.25, The way to compile Exiv2 (cmake or automake), the way to hide Exiv2 symbols from client application. Nothing work.

XMP sdk from Exiv2 still always visible.

It's also the case on my computer which do not crash, because by chance, the linker work better and pass to loader the most relevant XMP sdk symbols to use.
The Exiv2 XMP sdk symbols still visible with nm.

The ultimate solution that we found is to patch XMP sdk used in DNGConverter from digiKam core. We have used a dedicated C++ namespace. There is 2 commits relevant :

http://commits.kde.org/digikam/6d1c465f3224a6016f595fa820cce3873d2bcb86

http://commits.kde.org/digikam/e85634ac5d056e2e6ec9cfc82be198257011d667

I recommend to do the same in EXIV2 code about Adobe XMP SDK implementation.

Gilles Caulier

Gilles,

I can't reproduce this with exiv2 0.25 compiled with ./configure; make; make install, as I said above.
Exiv2 has been using the "C++ symbol visibility support for gcc builds" for a long time (#523). What you describe means that this feature is not working (anymore). If that's true, then that is a serious problem and it should be fixed properly.

Can you provide the steps to reproduce the issue? Or at least the nm -C output from such a faulty exiv2 library? Please make sure you're using exiv2 0.25 compiled with ./configure; make; make install. Not the one compiled with cmake.

Andreas

Hi all,

The problem is reproducible on my machine if I use CMake configuration

Mohamed

The crash problem is now fully reproducible using current implementation of Exiv2 from svn trunk. Exiv2 is compiled with Cmake. The option to use lib XMP as static shared lib tuned on or off do not fix the problem.

1/ A first stage, as i already reported previously, Exiv2 must be compiled with external symbols as private (xmp, curl, ssh, expat, etc...).

2/ But as Andreas said, the export symbols with cmake is also broken and must be fixed.

The patch attached fix 1/

Thanks, Gilles. I've submitted this r3973

I built and run the test suite as follows:

680 rmills@rmillsmbp:~/gnu/exiv2/trunk $ rm -rf ../build ; mkdir ../build ; cd ../build
681 rmills@rmillsmbp:~/gnu/exiv2/build $ cmake ../trunk -DEXIV2_ENABLE_WEBREADY=ON -DEXIV2_ENABLE_CURL=ON -DEXIV2_ENABLE_SSH=ON
-- Found CURL: /usr/lib/libcurl.dylib (found version "7.31.0") 
-- Found SSH: /usr/local/lib/libssh.dylib  
-- Program msgfmt found (/usr/local/bin/msgfmt)
-- None:              
-- Debug:             -g
-- Release:           -O3 -DNDEBUG
-- RelWithDebInfo:    -O2 -g -DNDEBUG
-- MinSizeRel:        -Os -DNDEBUG
-- ------------------------------------------------------------------
-- exiv2 0.25 configure results        <http://www.exiv2.org>
-- Building PNG support:               YES
-- Building shared library:            YES
-- XMP metadata support:               YES
-- Building static libxmp:             YES
-- Native language support:            YES
-- Conversion of Windows XP tags:      YES
-- Nikon lens database:                YES
-- Commercial build:                   NO
-- Build the unit tests:               YES
-- Building translations files:        NO
-- Building video support:             NO
-- Building webready support:          YES
-- USE Libcurl for HttpIo:             YES
-- USE Libssh for SshIo:               YES
-- ------------------------------------------------------------------
-- SVN version:  3972
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/rmills/gnu/exiv2/build
682 rmills@rmillsmbp:~/gnu/exiv2/build $ make ; sudo make install ; make tests

Running bugfixes-test.sh ...
426 440 443 444 445 447 452 460 479 480 495 498 501 528 540 554 662 666 683 711 726 751 769 784 799 800 812 831 (836 skipped) 841 876 884 922 935 937 937a 1026 1040 1043 1044 1053 1054 1058 1062 1112 1114 1122 
Files /Users/rmills/gnu/exiv2/trunk/test/tmp/bugfixes-test.out-stripped and /Users/rmills/gnu/exiv2/trunk/test/data/bugfixes-test.out differ
229,238c229,233
< Exif.Image.XPTitle                           Byte       40  Warning: Charset conversion required but no character mapping functionality available.
< 84 0 105 0 116 0 101 0 108 0 32 0 117 0 110 0 100 0 32 0 228 0 104 0 110 0 108 0 105 0 99 0 104 0 101 0 115 0 0 0
< Exif.Image.XPComment                         Byte       46  Warning: Charset conversion required but no character mapping functionality available.
< 65 0 110 0 100 0 32 0 97 0 32 0 115 0 116 0 97 0 110 0 100 0 97 0 114 0 100 0 32 0 99 0 111 0 109 0 109 0 101 0 110 0 116 0 0 0
< Exif.Image.XPAuthor                          Byte       44  Warning: Charset conversion required but no character mapping functionality available.
< 35 4 58 4 64 4 48 4 87 4 61 4 65 4 76 4 58 4 48 4 32 0 40 0 82 0 117 0 115 0 115 0 105 0 97 0 110 0 63 0 41 0 0 0
< Exif.Image.XPKeywords                        Byte       30  Warning: Charset conversion required but no character mapping functionality available.
< 226 5 209 5 232 5 217 5 234 5 32 0 40 0 72 0 101 0 98 0 114 0 101 0 119 0 41 0 0 0
< Exif.Image.XPSubject                         Byte       32  Warning: Charset conversion required but no character mapping functionality available.
< 36 12 70 12 50 12 65 12 23 12 65 12 32 0 40 0 84 0 101 0 108 0 117 0 103 0 117 0 41 0 0 0
---
> Exif.Image.XPTitle                           Byte       40  Titel und ähnliches
> Exif.Image.XPComment                         Byte       46  And a standard comment
> Exif.Image.XPAuthor                          Byte       44  Українська (Russian?)
> Exif.Image.XPKeywords                        Byte       30  עברית (Hebrew)
> Exif.Image.XPSubject                         Byte       32  తెలుగు (Telugu)
775d769
< Warning: Charset conversion required but no character mapping functionality available.
780,781c774,776
<   0000  55 4e 49 43 4f 44 45 00 41 20 55 6e 69 63 6f 64  UNICODE.A Unicod
<   0010  65 20 63 6f 6d 6d 65 6e 74                       e comment
---
>   0000  55 4e 49 43 4f 44 45 00 41 00 20 00 55 00 6e 00  UNICODE.A. .U.n.
>   0010  69 00 63 00 6f 00 64 00 65 00 20 00 63 00 6f 00  i.c.o.d.e. .c.o.
>   0020  6d 00 6d 00 65 00 6e 00 74 00                    m.m.e.n.t.
783,784d777
< Warning: Charset conversion required but no character mapping functionality available.
< Warning: Charset conversion required but no character mapping functionality available.
789c782
<   0000  55 4e 49 43 4f 44 45 00                          UNICODE.
---
>   0000  55 4e 49 43 4f 44 45 00 c4 01                    UNICODE...
791,792d783
< Warning: Charset conversion required but no character mapping functionality available.
< Warning: Charset conversion required but no character mapping functionality available.
797c788
<   0000  55 4e 49 43 4f 44 45 00 41 43                    UNICODE.AC
---
>   0000  55 4e 49 43 4f 44 45 00 41 00 c4 01 43 00        UNICODE.A...C.
799d789
< Warning: Charset conversion required but no character mapping functionality available.
804,805c794,795
<   0000  55 4e 49 43 4f 44 45 00 57 69 74 68 0a 4e 65 77  UNICODE.With.New
<   0010  6c 69 6e 65                                      line
---
>   0000  55 4e 49 43 4f 44 45 00 57 00 69 00 74 00 68 00  UNICODE.W.i.t.h.
>   0010  0a 00 4e 00 65 00 77 00 6c 00 69 00 6e 00 65 00  ..N.e.w.l.i.n.e.
807d796
< Warning: Charset conversion required but no character mapping functionality available.
812c801,802
<   0000  55 4e 49 43 4f 44 45 00 57 69 74 68 09 54 61 62  UNICODE.With.Tab
---
>   0000  55 4e 49 43 4f 44 45 00 57 00 69 00 74 00 68 00  UNICODE.W.i.t.h.
>   0010  09 00 54 00 61 00 62 00                          ..T.a.b.
814d803
< Warning: Charset conversion required but no character mapping functionality available.
819c808,809
<   0000  55 4e 49 43 4f 44 45 00 5c 75 67 67 67 67        UNICODE.\ugggg
---
>   0000  55 4e 49 43 4f 44 45 00 5c 00 75 00 67 00 67 00  UNICODE.\.u.g.g.
>   0010  67 00 67 00                                      g.g.
result = 1

I will not provide support for CMake, so I'm not going to investigate this. I'll check with the build server that the code is correctly built and passes the test suite when build with ./configure on *ix systems and Visual Studio on Windows.

This want mean that cmake support will be removed in the future ?

At least, just one build framework must be used to make library. It's a waste a time to support both framework at the same time, and this increase maintenance complexity. If automake/autoconf do the job, it's enough.

And i don't talk about all VC++ project files...

Just my 10cts...

Andreas,

On my computer Exiv2 from svn trunk is compiled with CMake.

The XMP symbols use (t) not (T) nm properties :

[gilles@localhost exiv2]$ nm -C /usr/lib/libexiv2.so |grep xmp
00000000002a94ce t GLOBAL_sub_I_xmp.cpp
00000000002b1e2c t GLOBAL_sub_I_xmpsidecar.cpp
00000000002a8a6f t (anonymous namespace)::xmpArrayType(unsigned long const&)
00000000002a8a90 t (anonymous namespace)::xmpArrayOptionBits(Exiv2::XmpValue::XmpArrayType)
00000000002a89d2 t (anonymous namespace)::xmpArrayOptionBits(Exiv2::XmpValue::XmpStruct)
00000000002a8aef t (anonymous namespace)::xmpFormatOptionBits(Exiv2::XmpParser::XmpFormatFlags)
00000000002a89a6 t (anonymous namespace)::xmpStruct(unsigned long const&)
000000000061ae00 b (anonymous namespace)::xmpHeaders
000000000061ae40 b (anonymous namespace)::xmpTrailers
000000000061ae80 b (anonymous namespace)::xmpTrailerEnd
00000000005ec3c0 D Exiv2::xmpAuxInfo
00000000005ea9c0 D Exiv2::xmpCrsInfo
00000000005f2500 D Exiv2::xmpDwCInfo
00000000005ea640 D Exiv2::xmpPdfInfo
00000000005e9380 D Exiv2::xmpXmpInfo
00000000005eb4c0 D Exiv2::xmpExifInfo
00000000005ec440 D Exiv2::xmpIptcInfo
00000000005e9280 D Exiv2::xmpKipiInfo
00000000005ecc40 D Exiv2::xmpPlusInfo
00000000005eb080 D Exiv2::xmpTiffInfo
00000000005f1c00 D Exiv2::xmpAudioInfo
00000000005ee640 D Exiv2::xmpGPanoInfo
00000000005ffac0 d Exiv2::xmpPrintInfo
00000000005eea00 D Exiv2::xmpVideoInfo
00000000005e9940 D Exiv2::xmpXmpBJInfo
00000000005e9ac0 D Exiv2::xmpXmpDMInfo
00000000005e9680 D Exiv2::xmpXmpMMInfo
00000000005f4440 D Exiv2::xmpAcdseeInfo
00000000005ec140 D Exiv2::xmpExifEXInfo
00000000005e99c0 D Exiv2::xmpXmpTPgInfo
00000000005f2340 D Exiv2::xmpDctermsInfo
00000000005e9140 D Exiv2::xmpDigikamInfo
00000000005ec6c0 D Exiv2::xmpIptcExtInfo
00000000005edf80 D Exiv2::xmpMediaProInfo
00000000005ea400 D Exiv2::xmpMicrosoftInfo
00000000005ea700 D Exiv2::xmpPhotoshopInfo
00000000005e9580 D Exiv2::xmpXmpRightsInfo
00000000005ee540 D Exiv2::xmpMWGKeywordInfo
00000000005ee380 D Exiv2::xmpMWGRegionsInfo
00000000005ee180 D Exiv2::xmpMicrosoftPhotoInfo
00000000005ee080 D Exiv2::xmpExpressionMediaInfo
00000000005ee280 D Exiv2::xmpMicrosoftPhotoRegionInfo
00000000005ee200 D Exiv2::xmpMicrosoftPhotoRegionInfoInfo
00000000001ea984 T Exiv2::Image::xmpData()
00000000001ea996 T Exiv2::Image::xmpPacket()
000000000030be30 R Exiv2::JpegBase::xmpId_
0000000000298a26 T Exiv2::XmpValue::xmpArrayType(Exiv2::TypeId)
000000000030b8c8 r Exiv2::ImageType::xmp
0000000000363ccc r Exiv2::ImageType::xmp
00000000005e8ec0 D Exiv2::xmpDcInfo
00000000005ea5c0 D Exiv2::xmpLrInfo
00000000005ff500 D Exiv2::xmpNsInfo
0000000000630f00 B Exiv2::XmpParser::xmpLockFct_
00000000001eadbe T Exiv2::Image::xmpData() const
00000000001eadfe T Exiv2::Image::xmpPacket() const
0000000000298a14 T Exiv2::XmpValue::xmpArrayType() const
0000000000298a6e T Exiv2::XmpValue::xmpStruct() const

... and digiKam still crash at startup :

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff78b984b in DngXmpSdk::WXMPMeta_RegisterNamespace_1 (namespaceURI=0x7fffe63ba6d8 "http://ns.adobe.com/lightroom/1.0/", suggestedPrefix=0x7fffe63ba6ce "lr", registeredPrefix=0x7fffffffcf70, prefixSize=0x7fffe63ba6ce, wResult=0xffffffff)
at /home/gilles/Devel/5.x/core/libs/3rdparty/dngwriter/extra/xmp_sdk/XMPCore/WXMPMeta.cpp:224
224 XMP_ENTER_WRAPPER ( "WXMPMeta_RegisterNamespace_1" )
(gdb) bt
#0 0x00007ffff78b984b in DngXmpSdk::WXMPMeta_RegisterNamespace_1(DngXmpSdk::XMP_StringPtr, DngXmpSdk::XMP_StringPtr, DngXmpSdk::XMP_StringPtr*, DngXmpSdk::XMP_StringLen*, DngXmpSdk::WXMP_Result*) (namespaceURI=0x7fffe63ba6d8 "http://ns.adobe.com/lightroom/1.0/", suggestedPrefix=0x7fffe63ba6ce "lr", registeredPrefix=0x7fffffffcf70, prefixSize=0x7fffe63ba6ce, wResult=0xffffffff) at /home/gilles/Devel/5.x/core/libs/3rdparty/dngwriter/extra/xmp_sdk/XMPCore/WXMPMeta.cpp:224
#1 0x00007fffe6300a9a in TXMPMeta<std::string>::RegisterNamespace(char const*, char const*) () at /lib/libexiv2.so.14
#2 0x00007fffe62fccac in Exiv2::XmpParser::initialize(void ()(void, bool), void*) () at /lib/libexiv2.so.14
#3 0x00007ffff4eacc9f in KExiv2Iface::KExiv2::initializeExiv2() () at /home/gilles/Devel/5.x/extra/libkexiv2/src/kexiv2.cpp:80
#4 0x0000000000406b98 in main(int, char**) (argc=1, argv=0x7fffffffda68) at /home/gilles/Devel/5.x/core/app/main/main.cpp:99
(gdb)

[gilles@localhost build]$ ldd /usr/bin/digikam |grep exiv2
libexiv2.so.14 => /lib/libexiv2.so.14 (0x00007fc1f40c4000)

Note that 3 XMP sdk entries have (b) nm properties.

The Exiv2 project will continue to have CMake support. However, I personally will not spend any more time on this matter. I've put a lot of time into this and, thanks to you, it works well on *nix systems. It's an unspeakable mess with Visual Studio. In addition, I have been unable to build openssl or curl with CMake using Visual Studio and my conclusion is that CMake/Visual Studio is not viable. If Daniel, or anybody else for that matter, wants to support CMake (with/without Visual Studio) that's totally OK with me. However I don't intend to waste any more time with CMake.

I think it would be better to open an Issue to track this matter. Two reasons:

1) Redmine/SVN integration logs changes into the issue report.
2) We compile the release notes from Issues and not forum topics.

http://dev.exiv2.org/issues/1123