headers
Pavel Ledin | 1 Apr 13:56
Picon
Favicon

Re[2]: 64 bit libHalf - R_X86_64_32S _eLut and -fPIC question

Hello Paul,

How did you solve your problem? I have same issue now on Mandriva
2008 x64 (and no any issue with x86).
How manually enable -fPIC?

/usr/bin/ld: ../../../OpenEXR/openexr-1.6.1/IlmImf/.libs/libIlmImf.a(ImfChannelList.o):
relocation R_X86_64_32S against `std::basic_string<char, std::char_traits<char>,
std::allocator<char> >::_Rep::_S_empty_rep_storage@@GLIBCXX_3.4' can not be used when making a
shared object; recompile with -fPIC
../../../OpenEXR/openexr-1.6.1/IlmImf/.libs/libIlmImf.a: could not read symbols: Bad value
collect2: ld returned 1 exit status

Thanks

Thursday, March 13, 2008, 10:11:02 PM, you wrote:

> Paul Miller wrote:

> A couple of people (thank you) pointed me in the right direction - I
> needed to manually tell the IlmBase configure script to enable PIC.

> Since fPIC is apparently *required* on x64 Linux, I was wondering why 
> the configure script didn't automatically enable it for me. Is that a 
> bug or a feature?

--

-- 
Best regards,
 Pavel Ledin aka Puppet                            mailto:puppet <at> rambler.ru
 TD, Trehmer
(Continue reading)

Permalink | Reply | 1 comment |
headers
Paul Miller | 1 Apr 15:12
Gravatar

Re: 64 bit libHalf - R_X86_64_32S _eLut and -fPIC question

Pavel Ledin wrote:
> Hello Paul,
> 
> How did you solve your problem? I have same issue now on Mandriva
> 2008 x64 (and no any issue with x86).
> How manually enable -fPIC?

There is an option in configure, near the end. I think it's --with-pic 
or --pic or something like that. Just enable it and you should be good.

> 
> /usr/bin/ld: ../../../OpenEXR/openexr-1.6.1/IlmImf/.libs/libIlmImf.a(ImfChannelList.o):
relocation R_X86_64_32S against `std::basic_string<char, std::char_traits<char>,
std::allocator<char> >::_Rep::_S_empty_rep_storage@@GLIBCXX_3.4' can not be used when making a
shared object; recompile with -fPIC
> ../../../OpenEXR/openexr-1.6.1/IlmImf/.libs/libIlmImf.a: could not read symbols: Bad value
> collect2: ld returned 1 exit status
> 
> Thanks
> 
> Thursday, March 13, 2008, 10:11:02 PM, you wrote:
> 
>> Paul Miller wrote:
> 
>> A couple of people (thank you) pointed me in the right direction - I
>> needed to manually tell the IlmBase configure script to enable PIC.
> 
>> Since fPIC is apparently *required* on x64 Linux, I was wondering why 
>> the configure script didn't automatically enable it for me. Is that a 
>> bug or a feature?
(Continue reading)

Permalink | Reply | 0 comments |
headers
James Wise | 10 Apr 16:18
Picon

vs2005 1.40 libs vs. 1.5.1 libs and B44 support

So i have been implementing OpenEXR support in my application.

Currently i am including headers and linking against the lib files.
I am using the lib files and header that came in the vs2005 archive form 
the website.
However i have noticed that this collection of files do not know about 
the B44 compression method,
and hence our application cannot read them.

So i got the latest source 1.6.1 files from the exr website and compiled 
the various projects as in the readme
however the lib that i have produced follwing this method are of  quite 
different sizes than the ones i got from the Vs2005 solution on the website?
notably the IlmImf.lib i make with 1.6.1 is around 1.9 Mb's whereas the 
one form the 1.40 vs2005 ditrobution is around 7.1 Mb's?
Also when i link against the new lib files, i get some errors about no 
eLUT , etc. see below....

imageio.lib(OpenEXRImporter.obj) : error LNK2001: unresolved external 
symbol "private: static unsigned short const * const half::_eLut" 
(?_eLut <at> half@@0QBGB)
1>image.lib(Pixel.obj) : error LNK2001: unresolved external symbol 
"private: static unsigned short const * const half::_eLut" 
(?_eLut <at> half@@0QBGB)
1>imageio.lib(OpenEXRImporter.obj) : error LNK2001: unresolved external 
symbol "private: static union half::uif const * const half::_toFloat" 
(?_toFloat <at> half@@0QBTuif <at> 1@B)
1>image.lib(Pixel.obj) : error LNK2001: unresolved external symbol 
"private: static union half::uif const * const half::_toFloat" 
(?_toFloat <at> half@@0QBTuif <at> 1@B)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Miller | 15 Apr 22:15
Gravatar

64 bit half.lib on win64?

I'm trying to build a windows 64 version of my app with an x64 version 
of half.lib (dynamic), but I keep getting multiple linker errors:

unresolved external symbol "private: static short __cdecl 
half::convert(int)"

I'm using the latest cvs drop, and I create a x64 build target for the 
half library vc8 project and built with that. My main program is finding 
the half.lib, but it just won't resolve the convert() function for some 
reason.

Anyone have any ideas here?

--

-- 
Paul Miller | paul <at> fxtech.com | www.fxtech.com | Got Tivo?
Permalink | Reply | 0 comments |
headers
Paul Miller | 16 Apr 03:04
Gravatar

Re: 64 bit half.lib on win64?

Nick Porcino wrote:
> Have you specified OPENEXR_DLL in your app/libs's preprocessor
> directives?

Yeah. I ended up linking in half.cpp statically to get it to work.

Didn't have this problem with the 32 bit build.

> 
> -----Original Message-----
> From: openexr-devel-bounces+nporcino=lucasarts.com <at> nongnu.org
> [mailto:openexr-devel-bounces+nporcino=lucasarts.com <at> nongnu.org] On
> Behalf Of Paul Miller
> Sent: Tuesday, April 15, 2008 1:15 PM
> To: openexr-devel <at> nongnu.org
> Subject: [Openexr-devel] 64 bit half.lib on win64?
> 
> I'm trying to build a windows 64 version of my app with an x64 version 
> of half.lib (dynamic), but I keep getting multiple linker errors:
> 
> unresolved external symbol "private: static short __cdecl 
> half::convert(int)"
> 
> I'm using the latest cvs drop, and I create a x64 build target for the 
> half library vc8 project and built with that. My main program is finding
> 
> the half.lib, but it just won't resolve the convert() function for some 
> reason.
> 
> Anyone have any ideas here?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Florian Kainz | 18 Apr 20:52

Re: [PATCH] openexr with gcc-4.3

Hi René,

thank you for sending your patch.  The problem was already
reported a few weeks ago, and a fix has been checked into CVS.

Florian

René Rebe wrote:
> Hi all,
> 
> some explicit incldues are required since g++-4.3 due to cleaned
> implicit includes e.g. also in the STL. Include string.h, as otherwise
> str* and mem* are unknown, otherwise.
> 
> Btw. if you keep some reference list of openexr users, you could add
> a link to the T2 SDE package:
> 
>   http://www.t2-project.org/packages/openexr.html
> 
> as well as our ExactImage, shipping with "basic" OpenEXR support
> for some time:
> 
>   http://www.exactcode.de/site/open_source/exactimage/
> 
> --- openexr-1.4.0/exrenvmap/main.cpp.vanilla    2008-04-09 
> 10:05:32.000000000 +0000
> +++ openexr-1.4.0/exrenvmap/main.cpp    2008-04-09 10:05:37.000000000 +0000
> @@ -45,6 +45,7 @@
>  #include <iostream>
>  #include <exception>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Miller | 29 Apr 23:10
Gravatar

extension mandate for stereo EXRs?

I'm currently writing my stereo EXR files with an .exr extension. Should 
I be forcing the extension to sxr when writing stereo? Currently, I 
don't give my users control over the extension, and I have some asking 
for the ability to name their stereo files with an .sxr extension.

--

-- 
Paul Miller | paul <at> fxtech.com | www.fxtech.com | Got Tivo?
Permalink | Reply | 1 comment |
headers
Florian Kainz | 30 Apr 02:48

Re: extension mandate for stereo EXRs?

The Multi-View OpenEXR document (see OpenEXR CVS repository) by
Peter Hillman and Matt Welford suggests that you should allow your
users to save stereo images with a .sxr extension (see below).

The .sxr extension allows software (and people) to identify stereo
images by looking at the file name.  A potential disadvantage of
the .sxr extension is that some application programs may assume
that all OpenEXR files have a .exr extension.  Those programs would
fail to open .sxr images even though they could read the files just
fine if they tried.

Florian

------------------

     File Name Extension Support

     Users may wish to save multi-view OpenEXR files with a file
     name extension other than the commonly used .exr, for example,
     .sxr for Stereo eXR, or .mxr for Multi-view eXR. The 3-letter
     extension space is crowded, but SXR and MXR are not heavily
     used. Either or both of these may become a standard for
     multi-view OpenEXR files.

     Meanwhile, it is recommended that software vendors provide a
     mechanism allowing users to identify which file name extensions
     they will employ for multi-view OpenEXR files. For example,
     software may understand the environment variable

         MULTIVIEW_EXR_EXT="SXR"
(Continue reading)

Permalink | Reply | 0 comments |

Gmane