Exiv2

Carsten

Thank you for reporting this.

This code compiles with g++ (on Linux and Cygwin) and with MSVC on Windows. So the solarisstudio compiler is unable to resolve his search for bool comparator(const Exiv2::Metadatum&,...).

The header is in metadatum.hpp (and the code in metadatum.cpp)
EXIV2API bool cmpMetadataByTag(const Metadatum& lhs, const Metadatum& rhs);

EXIV2API is a "house" decoration which I know for MSVC builds is set in exv_msvc.h I know because I contributed this to exv_msvc.h

For automake builds, the generated file exv_conf.h manages this and the EXIV2API decoration is not being correctly set for solaristudio. I've listed the relevant code in exv_conf.h from the cygwin/g++ build. You'll see there's a reference to __SUNPRO_C. I think you'll probably have to extend the __SUNPRO_C code to also respect solarisstudio.

The "source" file which generates exv_conf.h is config.h.in and when that's updated, I suspect:

$ make clean; ./configure --whatever... ; make

will make you happy.

One last observation. This declspec stuff relates to shared/DLL support. Simply doing ./configure --disable-shared --enable-static will probably build "out of the box" without changes. Of course you'll have a static build and that may (or may not) suit your purposes.

I hope this helps. If you are able to fix this, perhaps you could provide a patch file and I'll update the code base for other happy (or unhappy) users of solarisstudio.

Robin

/* Symbol visibility support */
#ifdef WIN32
# define EXV_IMPORT __declspec(dllimport)
# define EXV_EXPORT __declspec(dllexport)
# define EXV_DLLLOCAL
# define EXV_DLLPUBLIC
#else
# ifdef EXV_WANT_VISIBILITY_SUPPORT
#  if defined(__GNUC__) && (__GNUC__ >= 4)
#   define EXV_IMPORT __attribute__ ((visibility("default")))
#   define EXV_EXPORT __attribute__ ((visibility("default")))
#   define EXV_DLLLOCAL __attribute__ ((visibility("hidden")))
#   define EXV_DLLPUBLIC __attribute__ ((visibility("default")))
#  elif defined(__SUNPRO_C) && (__SUNPRO_C >= 0x550)
#   define EXV_IMPORT __global
#   define EXV_EXPORT __global
#   define EXV_DLLLOCAL __hidden
#   define EXV_DLLPUBLIC __global
#  else
#   define EXV_IMPORT
#   define EXV_EXPORT
#   define EXV_DLLLOCAL
#   define EXV_DLLPUBLIC
#  endif
# else /* ! EXV_WANT_VISIBILITY_SUPPORT */
#  define EXV_IMPORT
#  define EXV_EXPORT
#  define EXV_DLLLOCAL
#  define EXV_DLLPUBLIC
# endif /* ! EXV_WANT_VISIBILITY_SUPPORT */
#endif /* ! WIN32 */

/* Define EXIV2API for DLL builds */
#ifdef EXV_HAVE_DLL
# ifdef EXV_BUILDING_LIB
#  define EXIV2API EXV_EXPORT
# else
#  define EXIV2API EXV_IMPORT
# endif /* ! EXV_BUILDING_LIB */
#else
# define EXIV2API
#endif /* ! EXV_HAVE_DLL */

I can't see that this solves the problem. I guess that what you describe is related link problems, but I have a compile error.
Any other hints?

If the solarisstudio compiler has switch to trace loading header files, use that to be certain it read metadatum.hpp.

I found out that Solaris Studio Compiler works if I use the libstl:
see also: https://forums.oracle.com/forums/thread.jspa?threadID=2408487&tstart=0

I'm pleased to hear that you've got this to work. Exactly what do you have to do? Is it ./configure; make "CXXFLAGS=-library=libstl4" ; sudo make install ?

Yes, with CXXFLAGS=-library=libstl4 it compiles, but now I have link errors:

libtool: link: /opt/solarisstudio12.3/bin/CC -m32 -xarch=sparc -o .libs/taglist taglist.o -L/opt/csw/lib -L/home/cgrzemba/opencsw/exiv2/trunk/work/build-isa-sparcv8plus/exiv2-0.23/xmpsdk/src ./.libs/libexiv2.so -lintl -liconv -lz -lm -lexpat -library=stlport4 -R/opt/csw/lib
Undefined first referenced
symbol in file
bool Exiv2::ExifTags::isMakerGroup(const std::string &) taglist.o
void Exiv2::ExifTags::taglist(std::ostream &,const std::string &) taglist.o
void Exiv2::ExifTags::taglist(std::ostream &) taglist.o
void Exiv2::XmpProperties::printProperties(std::ostream &,const std::string &) taglist.o
bool Exiv2::ExifTags::isExifGroup(const std::string &) taglist.o
Exiv2::__RTTI__1nFExiv2IAnyError_ taglist.o
[Hint: static member Exiv2::__RTTI__1nFExiv2IAnyError_ must be defined in the program]

void Exiv2::IptcDataSets::dataSetList(std::ostream &) taglist.o
ld: fatal: symbol referencing errors. No output written to .libs/taglist
gmake¹: *** [taglist] Error 2

I've just now (last 30 mins) successfully build Exiv2 v0.23 on Solaris 11.1 using the Solaris Studio 12.3 compiler.
This is for my migration of darktable from using non-Oracle dependencies (ie, built from pkg.openindiana.org/sfe
supplied g++).

I used these environment settings:

CXXFLAGS="-D__SUNOS__=1 -D__unix__=1 -D__SSE3__ -D__SSE__ -D__SSE2__ -D__SSE4__ -DOS_SOLARIS=1 -lumem -xlibmil -xlibmopt -xO5 -D__SIZE_TYPE__=size_t -xarch=sse3 -library=stdcxx4"
LDFLAGS="-R/usr/lib:/opt/darktable/lib -L/usr/lib -lstdcxx4 -lm -lumem -lc"

I had to hack on the Makefiles to get various components to link correctly. It appears that some GNUisms are included
therein which Solaris Studio chokes on.

I also had to add a collection of #include files {blocked out via #if defined(OS_SOLARIS)} so that I could build this
package with the Apache stdcxx4 library.

I'll formalise the changes in the next few days (ie, tidy them up) and submit them as a patch against 0.23.

James

Thanks for updating this. It would be very helpful indeed for you to provide a patch.

I've put a link to this discussion on the Wiki Page: How do I build Exiv2 on the XYZ Platform http://dev.exiv2.org/projects/exiv2/wiki/How_do_I_build_Exiv2_on_the_XYZ_platform

You're aware open source works by contributors sharing their experience. You'll appreciate that without access to SolarisStudio, it's not possible for the Exiv2 team members to test anything on that platform. If you have time and enthusiasm, perhaps you could build try to build Exiv2 with CMake and record your experience on this thread.

Thanks very much for reporting your progress and success.

Robin

Building with cmake was much much easier than with the 0.23 tarball.

I've attached diffs to enable building with

#1 Solaris Studio 12.3
#2 Solaris 11.1
#3 using -library=stdcxx4 (the Apache stdcxx library).

For reference, Oracle Solaris Studio is available for Linux via download from http://www.oracle.com/technetwork/server-storage/solarisstudio/downloads/index-jsp-141149.html

The comments at the top of the attachment are

1. environment flags used
2. CC=cc
3. CFLAGS=-D__SUNOS__=1 -D__unix__=1 -D__SSE3__ -D__SSE__ -D__SSE2__ -D__SSE4__ -DOS_SOLARIS=1 -lumem -xO3 -xarch=sse3 -R/opt/darktable/lib -lumem
4. CXX=CC
5. CXXFLAGS=-D__SUNOS__=1 -D__unix__=1 -D__SSE3__ -D__SSE__ -D__SSE2__ -D__SSE4__ -DOS_SOLARIS=1 -lumem -xO3 -xarch=sse3 -library=stdcxx4 -R/opt/darktable/lib -lumem
6. LDFLAGS=-R/opt/darktable/lib -lumem
7. PATH=/opt/SUNWspro/solarisstudio12.3/bin:/usr/perl5/bin:/opt/local/bin:/usr/gcc/4.6/bin/:/usr/bin:/usr/sbin:/bin:/sbin:/usr/dt/bin:/usr/sfw/bin:/usr/gnu/bin:

1. This was for a CMake build. The CMake command line was
2. mkdir build && cd build
3. cmake .. -DCMAKE_INSTALL_PREFIX=/opt/darktable -DCMAKE_INSTALL_RPATH=/opt/darktable:/usr/lib ####

Note that I have references to Darktable in the env vars because that's my use-case, building the library because it's a pre-req for the application.
I'm the Solaris maintainer of Darktable and blog about it at http://www.jmcpdotcom.com/blog/category/darktable.

I haven't svn committed the changes; I was surprised that 'svn commit -m ...' wanted a dev.exiv2.org username.

Thanks for sending this, James. I'll have a look at it over the weekend and submit it to the repos on your behalf (I'll acknowledge you in the commit message). I'm sure you'll understand that we only grant write permission to our repos for "trusted friends". It's not personal. I worked for months on Exiv2 before being granted write access.

I assume that your patch is relative to the trunk (and not the 0.23 branch). My intention is to submit to trunk.

Thanks for letting me know that Oracle SolarisStudio's is a free download for Linux. One part of right-brain says "Ah, that'll be cool. More toys", and left-brain says "Not so fast, buster. That's yet another build/test platform.". Right-brain usually wins. I'll download and build with that.

Robin

James

Thanks very much for the patch. Submitted r3018. You're welcome as a build engineer on our team anytime. Thank You for this contribution.

I've pasted your note from the top of your file here to help somebody in future.

1. environment flags used
2. CC=cc
3. CFLAGS=-D__SUNOS__=1 -D__unix__=1 -D__SSE3__ -D__SSE__ -D__SSE2__ -D__SSE4__ -DOS_SOLARIS=1 -lumem -xO3 -xarch=sse3 -R/opt/darktable/lib -lumem
4. CXX=CC
5. CXXFLAGS=-D__SUNOS__=1 -D__unix__=1 -D__SSE3__ -D__SSE__ -D__SSE2__ -D__SSE4__ -DOS_SOLARIS=1 -lumem -xO3 -xarch=sse3 -library=stdcxx4 -R/opt/darktable/lib -lumem
6. LDFLAGS=-R/opt/darktable/lib -lumem
7. PATH=/opt/SUNWspro/solarisstudio12.3/bin:/usr/perl5/bin:/opt/local/bin:/usr/gcc/4.6/bin/:/usr/bin:/usr/sbin:/bin:/sbin:/usr/dt/bin:/usr/sfw/bin:/usr/gnu/bin:

1. This was for a CMake build. The CMake command line was
2. mkdir build && cd build
3. cmake .. -DCMAKE_INSTALL_PREFIX=/opt/darktable -DCMAKE_INSTALL_RPATH=/opt/darktable:/usr/lib ####

On Fedora 17 (64-bit):

I've tested revision 3019 of exiv2 from the svn trunk. Following are my observations:

The following methods of building and testing work fine without any problem(s).

GCC:

(i) ./configure ; make ; make samples; make tests
(ii) cmake <exiv2-dir> ; make ; make samples; make tests

SolarisStudio12.3: Tested on Fedora 17 (64-bit)

(i) cmake -DCMAKE_CXX_FLAGS=-library=stlport4 -DCMAKE_CXX_COMPILER=/opt/oracle/solarisstudio12.3/bin/CC -DCMAKE_C_COMPILER=/opt/oracle/solarisstudio12.3/bin/cc <exiv2-dir> ; make ; make samples ; make tests

Note: for linux platform, the option -DCMAKE_CXX_FLAGS=-library=stdcxx4 and -DCMAKE_CXX_FLAGS=-library=libstl4 both don't work. However, -DCMAKE_CXX_FLAGS=-library=stlport4 works. Also, couple of warnings arise.

The ./configure method for SolarisStudio doesn't work :

(ii) ./configure CXX=/opt/oracle/solarisstudio12.3/bin/CC CC=/opt/oracle/solarisstudio12.3/bin/cc CXXFLAGS=-library=stlport4
It gives the following error:

[Wani@Linux trunk]$ make
if test "x1" = "x1"; then cd xmpsdk/src && make xmpsdk; fi;
make¹: Entering directory `/home/Wani/GSoC/exiv2-trunk/trunk/xmpsdk/src'
libtool: compile: /opt/oracle/solarisstudio12.3/bin/CC -library=stlport4 -xldscope=hidden -I. -DEXV_LOCALEDIR=\"/usr/local/share/locale\" -I../include -funsigned-char -DNDEBUG=1 -DEXV_HAVE_STDINT_H=1 -c XML_Node.cpp -KPIC -DPIC -o .libs/XML_Node.o
CC: Warning: Option -funsigned-char passed to ld, if ld is invoked, ignored otherwise
libtool: compile: /opt/oracle/solarisstudio12.3/bin/CC -library=stlport4 -xldscope=hidden -I. -DEXV_LOCALEDIR=\"/usr/local/share/locale\" -I../include -funsigned-char -DNDEBUG=1 -DEXV_HAVE_STDINT_H=1 -c XML_Node.cpp -o XML_Node.o >/dev/null 2>&1
CC: Warning: Option -funsigned-char passed to ld, if ld is invoked, ignored otherwise
/opt/oracle/solarisstudio12.3/prod/lib/amd64/crt1x.o: In function `_start':
fsr.s:(.text+0x3b): undefined reference to `main'
make<sup>1</sup>: * [XML_Node.o] Error 2
make<sup>1</sup>: Leaving directory `/home/Wani/GSoC/exiv2-trunk/trunk/xmpsdk/src'
make: * [xmpsdk] Error 2
[Wani@Linux trunk]$

I've also tested revision 3020 of exiv2 from the svn trunk. Following are my observations:

The following methods of building and testing work fine without any problem(s).

GCC:

(i) ./configure ; make ; make samples; make tests
(ii) cmake <exiv2-dir> ; make ; make samples; make tests

These methods for SolarisStudio stop working:

SolarisStudio12.3:

(i) cmake -DCMAKE_CXX_FLAGS=-library=stlport4 -DCMAKE_CXX_COMPILER=/opt/oracle/solarisstudio12.3/bin/CC -DCMAKE_C_COMPILER=/opt/oracle/solarisstudio12.3/bin/cc <exiv2-dir> ; make ; make samples ; make tests
Error:
Scanning dependencies of target exiv2lib
[ 17%] Building CXX object src/CMakeFiles/exiv2lib.dir/asfvideo.cpp.o
"/home/Wani/GSoC/exiv2-trunk/trunk/src/error.cpp", line 29: Error: Multiple declaration for rcsId.
1 Error(s) detected.
make²: * [src/CMakeFiles/exiv2lib.dir/asfvideo.cpp.o] Error 2
make¹: [src/CMakeFiles/exiv2lib.dir/all] Error 2
make: ** [all] Error 2
[Wani@Linux trunk]$

(ii) ./configure CXX=/opt/oracle/solarisstudio12.3/bin/CC CC=/opt/oracle/solarisstudio12.3/bin/cc CXXFLAGS=-library=stlport4
[Wani@Linux trunk]$ make
if test "x1" = "x1"; then cd xmpsdk/src && make xmpsdk; fi;
make¹: Entering directory `/home/Wani/GSoC/exiv2-trunk/trunk/xmpsdk/src'
libtool: compile: /opt/oracle/solarisstudio12.3/bin/CC -library=stlport4 -xldscope=hidden -I. -DEXV_LOCALEDIR=\"/usr/local/share/locale\" -I../include -funsigned-char -DNDEBUG=1 -DEXV_HAVE_STDINT_H=1 -c XML_Node.cpp -KPIC -DPIC -o .libs/XML_Node.o
CC: Warning: Option -funsigned-char passed to ld, if ld is invoked, ignored otherwise
libtool: compile: /opt/oracle/solarisstudio12.3/bin/CC -library=stlport4 -xldscope=hidden -I. -DEXV_LOCALEDIR=\"/usr/local/share/locale\" -I../include -funsigned-char -DNDEBUG=1 -DEXV_HAVE_STDINT_H=1 -c XML_Node.cpp -o XML_Node.o >/dev/null 2>&1
CC: Warning: Option -funsigned-char passed to ld, if ld is invoked, ignored otherwise
/opt/oracle/solarisstudio12.3/prod/lib/amd64/crt1x.o: In function `_start':
fsr.s:(.text+0x3b): undefined reference to `main'
make<sup>1</sup>: * [XML_Node.o] Error 2
make<sup>1</sup>: Leaving directory `/home/Wani/GSoC/exiv2-trunk/trunk/xmpsdk/src'
make: * [xmpsdk] Error 2
[Wani@Linux trunk]$

I've attached the outputs of each case, which include warnings and errors.

Thanks, Nehal. You've gone to a lot of trouble and reported many results. I believe the summary is that Exiv2 r3020 builds and passes the test suite with GCC. I can confirm that it is also good on Cygwin (GCC 4.6.2), the Mac 10.8 (Xcode 4.6.2) and Kubuntu 12.10 (GCC 4.8.0).

• ./cmake #Fails! (with -library=stlport4)
• ./configure #Fails! (with -library=stlport4)

Regrettably, I have been unable to reproduce this because I been unable to install SolarisStudio 12.3 on my Kubuntu 12.10/64 system.

1. May I ask you to sync the trunk and build and test with SolarisStudio.
   - I added a change in r3020 to silence compiler warnings from rcsid_int.hpp.
   - If r3020 has broken the SolarisStudio build, can you suggest an alternative change.
2. Have you been able to build with the autotools - or do you only recommend CMake for SolarisStudio?
   - $ make distclean ; make config ; ./configure ; make ; sudo make install ; make samples ; make tests

Robin

I pulled r3020 and rebuilt. I regret to say that I didn't pay close enough attention to the preprocessed source in my earlier comments. When I tried to reduce the branches in the #if..#else for rcsId I observed the following behaviour:

"/scratch/src/photostuff/darktable/dependencies/exiv2-0.23-svn/src/asfvideo.cpp", line 30: Error: A declaration was expected instead of "{".
"/scratch/src/photostuff/darktable/dependencies/exiv2-0.23-svn/src/asfvideo.cpp", line 30: Error: A declaration was expected instead of "}".
2 Error(s) detected.

This occurred unless I commented out the line following the opening of the macro. Checking the pre-processed source resulting from that change lead me to the point of enlightenment: Studio C++ doesn't appear to allow multiline macros like this one for rcsId.

Using this block instead seems to be more correct, at the nominal expense of the rcsId ident string:

#if defined(__clang__) || (defined(OS_SOLARIS) && defined(__SUNPRO_CC))
#define EXIV2_RCSID(id)
#else
#define EXIV2_RCSID(id) \
    namespace { \
        inline const char* getRcsId(const char*) { return id ; } \
        const char* rcsId = getRcsId(rcsId); \
    }
#endif

Robin, in response to the other part of your question: I've only got this building via CMake. While I could go and hack up on the various g++ flags to remove those which conflict with Studio, or change them to the Studio equivalents, it's so much easier to use CMake instead that I won't bother.

Thank you James and Nehal for your work on this. Much appreciated. I've submitted 3021 which I believe will resolve the issue with src/rcsid_int.hpp. I've reversed the logic of the decision to accept or ignore the macro EXIV2_RCSID. Only GCC/G++/MSC will accept the EXIV2_RCSID. Hopefully, we're now good.

We are all in agreement that CMake should be used to build with the Oracle compilers and that ./configure (autotools) is broken.

1. Install the 32 bit libraries
2. use non-standard options for the compiler

Of course the compilers (cc for C, and CC for C++) must be on your path

$ sudo apt-get install libc6-dev-i386 libc6-i386 lib32gcc1 lib32z1 lib32stdc++6 ia32-libs -y
$ CC -m32 -L/lib32 -R/lib32 foo.cpp -o foo
CC: Warning: failed to detect system linker version, falling back to custom linker usage
$ ./foo

I've used Nehal's flags with CMake. It compiled xmpsdk and stopped at 29% on exif.cpp

$ export CFLAGS="-m32 -L/lib32 -R/lib32" 
$ export CXXFLAGS="-m32 -L/lib32 -R/lib32" 
$ export LDFLAGS="-m32 -L/lib32 -R/lib32" 
$ cmake -DCMAKE_CXX_COMPILER=CC -DCMAKE_C_COMPILER=cc relative-path-to-exiv
$ make

Robin

I have built r3021 on Fedora 17/6 with Solaris Studio Compiler 12.3. CMake was used. There were no problems with the compilation, but only warnings. Although the software compiled fine, one of the test cases produced a diff with the standard result. I have attached the file relating to that.

I also built r3021 with with GCC (./configure and Cmake) and there are no problems with the compilation and tests.