Campbell Barton | 4 Jan 15:35
Picon
Gravatar

Compiling ilmbase+openexr on solaris x86 64bit

Hi, Iv been getting blender3d to compile on Solaris10-x86 64bit (for
use on suns network.com grid computing engine, for the peach project
peach.blender.org)
I had quite a bit of trouble getting openexr built.

32bit would build with no problems, but compiling 64bit openexr
binaries was difficult.

The problem is that I could not tell it to look for libs in /usr/sfw/lib/amd64/
it would instead look for libstdc++ and in /usr/sfw/lib/ and give a
linking error when building.
This problem happens with ilmbase-1.0.1 and openexr-1.6.1

- "wrong ELF class: ELFCLASS64"

I tried ./configure --libdir=/usr/sfw/lib/amd64/ setting LDFLAGS but
it seemed I could not overwide the reference to /usr/sfw/lib/ and
there was no way to set it.

Anyhow here are the commands I used to compile, maybe it gives some
insights into the problem or at least help others in the meantime.

If anyones interested, heres some info about setting up the renderfarm
http://wiki.blender.org/index.php/Bf-institute/renderfarm

--------
PATH=$PATH:/usr/ccs/bin:/usr/sfw/bin:/opt/csw/bin
CFLAGS="-m64 -O2 -pipe -mtune=opteron"
CCFLAGS=$CFLAGS

(Continue reading)

Bob Friesenhahn | 4 Jan 17:18
Picon
Picon
Gravatar

Re: Compiling ilmbase+openexr on solaris x86 64bit

For building 64-bit on Solaris, I use small shell script wrappers to 
help ensure that correct options are passed.  For example, this is the 
text of a script called c++-64:

#!/bin/sh
exec c++ -m64 -march=opteron "$@"

I then specify CXX=c++-64 to the configure script.

In order to make building configure-based packages fairly easy, I use 
a separate install tree for 64-bit apps (e.g. /usr/local64) and then 
add a share/config.site script under that tree similar to the one 
attached.  The configure script automatically sources the config.site 
file, which supplies default options.  The advantage of this approach 
is that selection of a 64-bit build may be specified by the --prefix 
option to the configure script and then the configure script 
automatically uses the right options and everything just works.  So 
one install prefix is used for 32-bit apps and another is used for 
64-bit apps.

Last I heard, Solaris was being dropped from OpenEXR's "supported" 
list.  Hopefully someone will have the sense to add it back.

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

Rex Dieter | 7 Jan 15:38
Favicon
Gravatar

pkgconfig patches (ilmbase, openexr)

Here are a couple of pkgconfig-related patches that move items required only
for static linking from
Libs:
to 
Libs.private:

We're using these in fedora (and epel) packages.

-- Rex
_______________________________________________
Openexr-devel mailing list
Openexr-devel <at> nongnu.org
http://lists.nongnu.org/mailman/listinfo/openexr-devel
Paul Miller | 11 Jan 17:48
Gravatar

Re: VC8 build errors using CVS

Ben Ochoa wrote:
> I just grabbed the latest from CVS and tried building it using VC8 under 
> Windows.  In the IlmBase solution, the ImathTest projects failed to 
> build.  In the OpenEXR solution, all 8 of the projects failed to build. 
>  Attached are the build logs from VC8.  Any thoughts?

You probably already figured it out, but just in case: you need to add 
the rest of the source files from IlmImf into the project. The vcproj in 
the CVS has not been updated with all of the new code.

--

-- 
Paul Miller | paul <at> fxtech.com | www.fxtech.com | Got Tivo?
Paul Miller | 11 Jan 17:49
Gravatar

How about an RGBAInputFile::setLayer() function?

How about a function to target the layer after the file header has 
already been read? Since I can't find out what layers are in the file 
until after opening the file, the only way to target the non-default 
layer is to delete the file and re-open with the new layer name.

--

-- 
Paul Miller | paul <at> fxtech.com | www.fxtech.com | Got Tivo?
Rex Dieter | 16 Jan 15:52
Favicon
Gravatar

Re: pkgconfig patches (ilmbase, openexr)

Rex Dieter wrote:

> Here are a couple of pkgconfig-related patches that move items required
> only for static linking from
> Libs:
> to
> Libs.private:
> 
> We're using these in fedora (and epel) packages.

Here's a followup, and improved pkgconfig patch for openexr-1.6.1.

In short, moves -lz to Libs.private (only required for static linking), and
omits direct references to ilmbase clags/libs, using
Requires: IlmBase
to inherit these automatically.

-- Rex
_______________________________________________
Openexr-devel mailing list
Openexr-devel <at> nongnu.org
http://lists.nongnu.org/mailman/listinfo/openexr-devel
Bob Friesenhahn | 16 Jan 16:47
Picon
Picon
Gravatar

Re: Re: pkgconfig patches (ilmbase, openexr)

On Wed, 16 Jan 2008, Rex Dieter wrote:
>>
>> We're using these in fedora (and epel) packages.
>
> Here's a followup, and improved pkgconfig patch for openexr-1.6.1.
>
> In short, moves -lz to Libs.private (only required for static linking), and
> omits direct references to ilmbase clags/libs, using
> Requires: IlmBase
> to inherit these automatically.

This will only work on systems which automatically add libraries due 
to this "inheritance".  Other systems will simply fail to link, 
leading to frustration and bug reports.  Are you sure you want to do 
this?

Bob
======================================
Bob Friesenhahn
bfriesen <at> simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
Rex Dieter | 16 Jan 16:50
Favicon
Gravatar

Re: Re: pkgconfig patches (ilmbase, openexr)

Bob Friesenhahn wrote:
> On Wed, 16 Jan 2008, Rex Dieter wrote:
>>>
>>> We're using these in fedora (and epel) packages.
>>
>> Here's a followup, and improved pkgconfig patch for openexr-1.6.1.
>>
>> In short, moves -lz to Libs.private (only required for static 
>> linking), and
>> omits direct references to ilmbase clags/libs, using
>> Requires: IlmBase
>> to inherit these automatically.
> 
> This will only work on systems which automatically add libraries due to 
> this "inheritance". 

The "inhertance" is simply a pkg-config feature, and should(?) work on 
all platforms pkgconfig supports.

-- Rex
Rex Dieter | 16 Jan 16:55
Favicon
Gravatar

Re: Re: pkgconfig patches (ilmbase, openexr)

Rex Dieter wrote:

> Bob Friesenhahn wrote:
>> On Wed, 16 Jan 2008, Rex Dieter wrote:
>>>>
>>>> We're using these in fedora (and epel) packages.
>>>
>>> Here's a followup, and improved pkgconfig patch for openexr-1.6.1.
>>>
>>> In short, moves -lz to Libs.private (only required for static
>>> linking), and
>>> omits direct references to ilmbase clags/libs, using
>>> Requires: IlmBase
>>> to inherit these automatically.
>> 
>> This will only work on systems which automatically add libraries due to
>> this "inheritance".
> 
> The "inhertance" is simply a pkg-config feature, and should(?) work on
> all platforms pkgconfig supports.

To be more clear, adding
Requires: IlmBase
does the same that was hard-coded previously, (automatically) adding
IlmBase's cflags, libs to the output of:
pkg-config --cflags --libs OpenEXR

End result should be the same.

-- Rex
(Continue reading)

Bob Friesenhahn | 16 Jan 17:19
Picon
Picon
Gravatar

Re: Re: Re: pkgconfig patches (ilmbase, openexr)

On Wed, 16 Jan 2008, Rex Dieter wrote:
>>> This will only work on systems which automatically add libraries due to
>>> this "inheritance".
>>
>> The "inhertance" is simply a pkg-config feature, and should(?) work on
>> all platforms pkgconfig supports.
>
> To be more clear, adding
> Requires: IlmBase
> does the same that was hard-coded previously, (automatically) adding
> IlmBase's cflags, libs to the output of:
> pkg-config --cflags --libs OpenEXR

That sounds ok.  I had thought that your intent was to rely on ELF 
dependency information, which is definitely not portable.  Sorry for 
the confusion.

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

Gmane