Hi, this is a new ebuild i've created for ILM's new HDR Image file format library called OpenEXR. It's a 16 bit file format, that can save files with lossless compression, and you can save several channels in the same file and add custom data to the file. It can use x11-libs/fltk, but it's not really required for successfull building of the libs, fltk is only used for the utillities as far as i can see. I would suggest using media-libs for this ebuild. Kim
Created attachment 7553 [details] OpenEXR-1.0.4.ebuild
Created attachment 7623 [details] New ebuild that patches the configure so it will detech fltk properly This is a modified ebuild that patches the configure script so that it detects fltk and uses it to build the exrdisplay app. I have also attached a patch that should reside in the files directory.
Created attachment 7624 [details, diff] The patch that the modified ebuild needs This is the diff that patches the configure script, so it will detect fltk.
Library for reading an ILM graphics file format (OpenEXR). Not really my thing. Returning to bug-wranglers.
I tried the ebuild as well as a pure compile of the app. it breaks badly with : g++ -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"OpenEXR\" -DVERSION=\"1.0.4\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_X11=1 -DSTDC_HEADERS=1 -DHAVE_LIMITS_H=1 -DHAVE_UNISTD_H=1 -DHAVE_STRERROR=1 -Drestrict= -I. -I. -I.. -I../Half -I../Iex -I../Imath -O2 -funroll-loops -pipe -march=i686 -UVERSION -g -O2 -c ImfBoxAttribute.cpp -Wp,-MD,.deps/libIlmImf_la-ImfBoxAttribute.TPlo -fPIC -DPIC -o .libs/libIlmImf_la-ImfBoxAttribute.lo In file included from ImfBoxAttribute.cpp:44: ImfAttribute.h: In instantiation of `Imf::TypedAttribute<Imath::Box<Imath::Vec2<int> > >': ImfBoxAttribute.h:55: instantiated from here ImfAttribute.h:230: cannot adjust access to `static void Imf::Attribute::registerAttributeType(const char *, Imf::Attribute * (*)())' in `class Imf::TypedAttribute<Imath::Box<Imath::Vec2<int> > >' ImfAttribute.h:379: because of local method `static void Imf::TypedAttribute<Imath::Box<Imath::Vec2<int> > >::registerAttributeType()' with same name ImfAttribute.h:230: cannot adjust access to `static void Imf::Attribute::unRegisterAttributeType(const char *)' in `class Imf::TypedAttribute<Imath::Box<Imath::Vec2<int> > >' ImfAttribute.h:387: because of local method `static void Imf::TypedAttribute<Imath::Box<Imath::Vec2<int> > >::unRegisterAttributeType()' with same name ImfAttribute.h: In instantiation of `Imf::TypedAttribute<Imath::Box<Imath::Vec2<float> > >': ImfBoxAttribute.h:61: instantiated from here ImfAttribute.h:230: cannot adjust access to `static void Imf::Attribute::registerAttributeType(const char *, Imf::Attribute * (*)())' in `class Imf::TypedAttribute<Imath::Box<Imath::Vec2<float> > >' ImfAttribute.h:379: because of local method `static void Imf::TypedAttribute<Imath::Box<Imath::Vec2<float> > >::registerAttributeType()' with same name ImfAttribute.h:230: cannot adjust access to `static void Imf::Attribute::unRegisterAttributeType(const char *)' in `class Imf::TypedAttribute<Imath::Box<Imath::Vec2<float> > >' ImfAttribute.h:387: because of local method `static void Imf::TypedAttribute<Imath::Box<Imath::Vec2<float> > >::unRegisterAttributeType()' with same name make[1]: *** [libIlmImf_la-ImfBoxAttribute.lo] Error 1 make[1]: Leaving directory `/local/henti/exr/OpenEXR-1.0.4/IlmImf' make: *** [all-recursive] Error 1 Not sure at all why this is ... just thought I'd let you know Henti Smith
With help from Lourens Veen <lourens@rainbowdesert.net> this has been ID'ed as a problem with gcc 2.95. Attached is the patched and updated ebuild to compile correctly on gentoo machines. Please test for other compilers. Henti Smith
Created attachment 9215 [details] Update ebuild with gcc 2.95 workaround This will now comile on gentoo 1.2 and gcc 2.95
Created attachment 9216 [details, diff] gcc 2.95 patch for OpenEXR Patch for updated ebuild with gcc 2.95 workaround
The ebuild is still not complete .. I noticed (silly of my really) that the configure by default into /usr/local/bin .. will fix that Henti Smith
Side note. 1.4 gcc 3.22 and distcc doens't seem to compile. removing distcc from FEATURE fixes it and compiles fine. other then that seems fine. doing last tests on new ebuild that installs into /usr as should be Henti Smith
I have to do some tweaking to our fltk packages
Created attachment 9377 [details] updated ebuild for installing into /usr instead of /usr/local This updates the install patch to /usr instead of /usr/local Will also attach install-base with qpkg -l OpenEXR in it
Created attachment 9378 [details] Installed package file listing list of installed files from qpkg -l OpenEXR
Bouncing back to bug-wranglers in the hope that someone with more time and 'net connectivity than me can commit all the hard work put in by Henti and Kim.
1.0.5 is out .. I've got a working ebuild .. but there is some new support I wanna add in, The ebuild uses the NVSDK if on the system, and since there is no NVSDK USE setting .. how can I enable and disable the use thereof ... just check if it's there ... if not .. don't .... I assume .. I'll work on it .. Also the ebuild needs the NEW NVSDK to work .. I'm still working on the ebuild .. it's a mess ... badly ... I'll add the 1.0.5 ebuild without NVSDK for now Henti
Created attachment 9753 [details] OpenEXR-1.0.5.ebuild New ebuild for 1.0.5 of OpenEXR adds IlmImf example program NVSDK is still broken, busy working on updated ebuild for that Henti
Ok ... new ebuild to work with NVSDK (I'll submit the ebuild as well and link it) Henti
Created attachment 9890 [details] New ebuild with NVSDK support This new ebuild adds NVSDK support to OpenEXR-1.0.5 Henti
Created attachment 9891 [details, diff] Patch for new ebuild to get NVSDK test in configure to work correctly Thanks to Drew Hess <dhess@ilm.com> from ILM for help sorting this out.
I see this has been assigned to somebody again .. does this mean it's actually being looked at again ? If so openexr has been updated to 1.0.6 and I have been working on the ebuild, but I'm not keen on putting work intot his again just to get ignored again. so let me know. bain
I've committed OpenEXR-1.0.6 in cvs as media-libs/openexr. Thanks for the ebuild, patches, and above all patience Henti. :)
Which ebuild did you use the current one or did you update it to version 1.0.6? The latest on bugs.gentoo is only to 1.0.5 as I've been working on 1.0.6 in portage overley for myself and have not updated yet ?
henti, I used your ebuild that included the NVSDK hack as a template and updated to 1.0.6 :)
