OpenEXR developer list

headers Peter Windey | 1 Mar 02:55

_______________________________________________
Openexr-devel mailing list
Openexr-devel <at> nongnu.org
http://lists.nongnu.org/mailman/listinfo/openexr-devel

Thanks for the patch.  The fix has been checked into CVS.

Florian

Rex Dieter wrote:
> Needed this small patch to build w/gcc-4.3
> 
> -- Rex
> 
> 
> ------------------------------------------------------------------------
> 
> diff -up openexr-1.6.1/exrmaketiled/main.cpp.gcc43 openexr-1.6.1/exrmaketiled/main.cpp
> --- openexr-1.6.1/exrmaketiled/main.cpp.gcc43	2007-04-24 20:08:45.000000000 -0500
> +++ openexr-1.6.1/exrmaketiled/main.cpp	2008-02-01 08:21:29.000000000 -0600
> @@ -44,7 +44,7 @@
>  
>  #include <iostream>
>  #include <exception>
> -#include <string>
> +#include <string.h>
>  #include <stdlib.h>
>  
>  using namespace Imf;
> diff -up openexr-1.6.1/exrenvmap/main.cpp.gcc43 openexr-1.6.1/exrenvmap/main.cpp
> --- openexr-1.6.1/exrenvmap/main.cpp.gcc43	2007-04-24 20:07:51.000000000 -0500
> +++ openexr-1.6.1/exrenvmap/main.cpp	2008-02-01 08:22:10.000000000 -0600
> @@ -45,6 +45,7 @@
>  #include <iostream>
>  #include <exception>
>  #include <stdlib.h>
> +#include <string.h>
>  
>  using namespace Imf;
>  using namespace std;
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Openexr-devel mailing list
> Openexr-devel <at> nongnu.org
> http://lists.nongnu.org/mailman/listinfo/openexr-devel

Well, this is a strange one.

I'm building libHalf statically on a 32 bit kubuntu system and a 64 bit 
system. I'm linking it in with a shared library.

On the 32 bit system, everything is fine.

On the 64 bit system (kubuntu 6.0.6, full upgrade), when I attempt to 
link my shared library (again, with the 64 bit static libHalf.a), I get 
this link error:

/usr/bin/ld: /usr/local/lib/libHalf.a(half.o): relocation R_X86_64_32S 
against half::_eLut' can not be used when making a shared object; 
recompile with -fPIC
/usr/local/lib/libHalf.a: could not read symbols: Bad value
collect2: ld returned 1 exit status

Can anyone shed any light on this? What's the difference in behavior 
between the 32 bit and 64 bit systems (basically, IDENTICAL setups 
except for the bit size) and what exactly is it asking for?

Much appreciated!!

--

-- 
Paul Miller | paul <at> fxtech.com | www.fxtech.com | Got Tivo?

Paul Miller wrote:
> Well, this is a strange one.
> 
> I'm building libHalf statically on a 32 bit kubuntu system and a 64 bit 
> system. I'm linking it in with a shared library.
> 
> On the 32 bit system, everything is fine.
> 
> On the 64 bit system (kubuntu 6.0.6, full upgrade), when I attempt to 
> link my shared library (again, with the 64 bit static libHalf.a), I get 
> this link error:

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?

--

-- 
Paul Miller | paul <at> fxtech.com | www.fxtech.com | Got Tivo?

On Thu, 13 Mar 2008, Paul Miller wrote:
>
> 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?

Normally PIC is used in shared libraries, and not in archive (.a) 
files.  The only exception that I have heard of is AIX, which seems to 
use .a files as shared libraries.

Perhaps you need to use --enable-shared to build shared libraries and 
use the shared libraries?

Bob
======================================
Bob Friesenhahn
bfriesen <at> simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

Bob Friesenhahn wrote:
> On Thu, 13 Mar 2008, Paul Miller wrote:
>>
>> 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?
> 
> Normally PIC is used in shared libraries, and not in archive (.a) 
> files.  The only exception that I have heard of is AIX, which seems to 
> use .a files as shared libraries.
> 
> Perhaps you need to use --enable-shared to build shared libraries and 
> use the shared libraries?

I didn't want to use shared libs because then I'd have a dependency 
problem and have to deal with -rpath and such. With all of my 
(non-system) dependencies built statically, I can basically plop my app 
(and its plugins) anywhere and it'll work without setting env vars, 
which is much nicer (I think).

--

-- 
Paul Miller | paul <at> fxtech.com | www.fxtech.com | Got Tivo?

On 14/03/2008, at 9:08 AM, Paul Miller wrote:
> Bob Friesenhahn wrote:
>> On Thu, 13 Mar 2008, Paul Miller wrote:
>>>
>>> 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?
>> Normally PIC is used in shared libraries, and not in archive (.a)  
>> files.  The only exception that I have heard of is AIX, which seems  
>> to use .a files as shared libraries.
>> Perhaps you need to use --enable-shared to build shared libraries  
>> and use the shared libraries?
>
> I didn't want to use shared libs because then I'd have a dependency  
> problem and have to deal with -rpath and such. With all of my (non- 
> system) dependencies built statically, I can basically plop my app  
> (and its plugins) anywhere and it'll work without setting env vars,  
> which is much nicer (I think).
>

You can still achieve that kind of portability while using shared  
libraries if you distribute the shared libraries with your app.  All  
you have to do is tell the linker that the shared libraries are  
relative to the executable by using a combination of the "-z origin"  
linker option and using $ORIGIN in your rpath.

For example, I have an app whose executable lives in a directory

     myApp/bin/myApp

And there are a bunch of shared libraries in

     myApp/lib

I set the rpath on myApp to

     $ORIGIN/../lib

and pass "-z origin" to the linker to activate it.  I've even  
distributed libstdc++ and libgcc_s with an app that way to reduce  
compiler version dependencies.

--Ken

Ken McGaugh wrote:
> On 14/03/2008, at 9:08 AM, Paul Miller wrote:
>> Bob Friesenhahn wrote:
>>> On Thu, 13 Mar 2008, Paul Miller wrote:
>>>>
>>>> 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?
>>> Normally PIC is used in shared libraries, and not in archive (.a) 
>>> files.  The only exception that I have heard of is AIX, which seems 
>>> to use .a files as shared libraries.
>>> Perhaps you need to use --enable-shared to build shared libraries and 
>>> use the shared libraries?
>>
>> I didn't want to use shared libs because then I'd have a dependency 
>> problem and have to deal with -rpath and such. With all of my 
>> (non-system) dependencies built statically, I can basically plop my 
>> app (and its plugins) anywhere and it'll work without setting env 
>> vars, which is much nicer (I think).
>>
> 
> You can still achieve that kind of portability while using shared 
> libraries if you distribute the shared libraries with your app.  All you 
> have to do is tell the linker that the shared libraries are relative to 
> the executable by using a combination of the "-z origin" linker option 
> and using $ORIGIN in your rpath.

...

> and pass "-z origin" to the linker to activate it.  I've even 
> distributed libstdc++ and libgcc_s with an app that way to reduce 
> compiler version dependencies.

Hmm - I wasn't aware of the -z option. Cool, thanks!

--

-- 
Paul Miller | paul <at> fxtech.com | www.fxtech.com | Got Tivo?

_______________________________________________
Openexr-devel mailing list
Openexr-devel <at> nongnu.org
http://lists.nongnu.org/mailman/listinfo/openexr-devel

For instruction on how to get access to CVS, please see this web page:

	http://savannah.nongnu.org/cvs/?group=openexr

If you just want to browse the CVS repository or download individual files,
then go to this page:

	http://cvs.savannah.nongnu.org/viewvc/?root=openexr

Hai Nguyen wrote:
> Hi,
> 
> I was wondering how I could get read only access to the current CVS or 
> SVN tree of OpenEXR if possible? I tried looking for the information on 
> the web page - but I couldn't find it. 
> 
> Thanks,
> - Hai 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Openexr-devel mailing list
> Openexr-devel <at> nongnu.org
> http://lists.nongnu.org/mailman/listinfo/openexr-devel

Mon	Tue	Wed	Thu	Fri	Sat	Sun

					1	2
3	4	5	6	7	8	9
10	11	12	13	14	15	16
17	18	19	20	21	22	23
24	25	26	27	28	29	30
31

6	February 2012
2	January 2012
2	November 2011
8	September 2011
12	August 2011
5	July 2011
2	June 2011
18	May 2011
15	April 2011
15	January 2011
9	November 2010
9	October 2010
6	September 2010
34	August 2010
4	June 2010
6	May 2010
31	March 2010
5	February 2010
12	December 2009
2	November 2009
2	October 2009
11	September 2009
11	July 2009
18	June 2009
4	May 2009
23	March 2009
5	February 2009
7	January 2009
4	December 2008
6	November 2008
18	October 2008
10	September 2008
11	August 2008
4	July 2008
19	June 2008
9	May 2008
8	April 2008
11	March 2008
12	February 2008
11	January 2008
30	December 2007
13	November 2007
9	October 2007
3	September 2007
26	August 2007
2	July 2007
11	June 2007
33	May 2007
11	April 2007
47	March 2007
9	February 2007
35	January 2007
49	December 2006
22	October 2006
23	September 2006
19	August 2006
17	July 2006
27	June 2006
11	May 2006
15	April 2006
29	March 2006
23	February 2006
55	January 2006
22	December 2005
17	November 2005
17	October 2005
10	September 2005
15	August 2005
48	July 2005
18	June 2005
14	May 2005
20	April 2005
91	March 2005
51	February 2005
27	January 2005
13	December 2004
54	November 2004
45	October 2004
57	September 2004
74	August 2004
17	July 2004
52	June 2004
58	May 2004
21	April 2004
35	March 2004
34	February 2004
112	January 2004
39	December 2003
31	November 2003
45	October 2003
9	September 2003
25	August 2003
25	July 2003
18	June 2003
16	May 2003
57	April 2003
116	March 2003
16	February 2003
58	January 2003
2	March 2002

An issue with openEXR under MSVC 2005 express

Re: openexr gcc43 patch

64 bit libHalf - R_X86_64_32S _eLut and -fPIC question

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

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

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

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

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

Repository Access

Re: Repository Access