OSX tiger build not linked against EXR library

The file errorlog2 was added: error log

I assume you used the stand-alone version of enblend which I advised for Tiger users. However, that one has the problem that it's not linked against (the static) openexr. Therefore it can't open exr files.
I tried to build the static Tiger enblend/enfuse versions 2 or 3 times but it still doesn't link against openexr, while the dynamic (snow)leopard version does.

So for the time being it's not possible to create hdr/exr images via enblend on Tiger. At least not with my builds.

I did indeed use the stand-alone enblend.

Thanks for you quick answer! I will just give it up then :)

I realise that there are not so many tiger users out there anymore, and certainly there will be none among active developers, but maybe there are more like me. And if there would be some spare time, it would be fantastic to add a Tiger-check plus warning that when creating HDR's, that this will fail. Or maybe just a sentence on the download page or where you advise to use another enblend.

But I fully realise that there is not time for everything - I already appreciate highly all the effort in this piece of software!

Harry, you see what you do with this. EMail me if you're not in the bughunters group to modify the states. (or mail Yuv to have yourself added).

Hi Rogier,

I appreciate the energy you are putting into cleaning up / sorting out the bug tracker.

Re bughunters group, everybody can apply to become a member by hitting the appropriate link on its homepage https://launchpad.net/~hugin-bug-hunters and everybody can ee who is a member by hitting another link on that page. You can see there that Harry is a team member.

Furthermore, you can see on the right hand side of this bug report who is subscribed / also notified.

If you want to attract the attention of somebody to a particular bug report, use the "Subscribe someone else" link on the right hand side to add them (if they are not already notified) and then post a rationale for why you added them so that they will be notified with that rationale.

Assigning a ticket to a person is a much stronger signal and can be misinterpreted. Developers assign tickets to themselves when they take responsibility for actually fixing a bug, and this will signal to other developers that they don't need to look into the matter. I don't mind when you assign me a ticket that you want me to look into, and in quieter times I will probably give them higher priority. I receive notifications for all tickets and at the moment I am not prioritizing my work through the tracker at all, just going ticket after ticket in my inbox. Assignment may be counter-productive under these conditions. I will leave it up to Harry to decide if he wants to de-assign himself.

I didn't look into this issue for a couple of weeks. I will look into it the coming days. The assignment is OK.

I just saw Yuv's comment that I shouldn't have done the assignment, found that I could remove you, and then saw your comment. Anyway. You're subscribed at least. Reassign yourself if you want to.

Although you could interpret "assigned to XX" as "XX will fix it and he's not allowed to sleep before he does", I would like to interpret it as: Action on this bug can come from only one person.

So in this case, Harry is "our" builder for Macos, and he's the one who can decide weather or not to build in a different way, to allow this desired feature to be present in the pre-built bundles or not. Or he can decide to say: Sorry I (still) can't manage to build the standalone version with ....

I have assigned a few bug reports to you as well. I'm sorry if you feel pressured by that. Don't be.
As far as I know, you're also in the "bug hunters" team, and will already get the Emails about all the bug changes. With me adding 10-20 comments a day, that will prove to be a pile. I can understand if you don't have the time to read up on all of them. So just subscribing you specifically won't really make a noticable change in your inbox. So when I think an action from specifically you is required, do you mind if I "assign" the report to you? And again, it's not that I think you HAVE to take action within 24 hours, it's just that you're the most appropriate person to have a look at it.

Rogier, I don't mind you subscribing me if you think I should look at a bug specifically.

Yes, the pile is quite high at the moment and I am struggling to work through it. I use all possible free time. Eventually we'll be gone through all imported reports and the quantity will subside. I don't feel pressured - I have intentionally kicked off the migration at this time of the year and I knew what was coming. And I am not alone in this, I am thankful to all of you out here helping sorting out the 400+ reports tsunami. On most mail I just hit the delete button. on some I add tags. on a few I comment. a very few I keep for later because there are things to do there that I can't do in a few minutes. Food is ready now, so my time is over for now. Will be back on the tracker probably tonight.

This report does not belong here at all. It is not a problem related to
the source code of Enblend (or Enfuse). Quite the contrary is true:
we have the feature of compiling with or without EXR support. Obviously,
the original poster's version was built without it. The error message
couldn't be much clearer.

The user will either need a version with EXR support compiled in or
recode his files as floating-point TIFFs and feed these into Enblend.

I have clarified the documentation with changeset d8a85b28263f, so
that we can just say "RTFM" in the future.

Christoph, Even though you're a (the?) major enblend developer, this fact doesn't make this into your private bug-database or "todo list".

Developing open source is a cooperation effort between different people. Each doing what they are good at. . You're the one who "messes around" with the source. That's what you do best. Harry is the one who volunteered to build OSX binaries. So this item is on his "todo list". He'll look into it when he has time. He can and will mark this as resolved once he gets around to it. OK?

@Christoph: you are right: it is not a source code problem. It is however a build/distribution problem and I think it makes sense to track those here as well, especially since we have Harry here who does indeed work on fixing them.

Let's use tags and the other features that LP offers us to categorize what is source code related and what is build related, rather than being unfriendly and reject tickets outright. One of the main points in selecting LP was that we can avoid invalidating reports that do have merits (though not completely on topic) and this one has. I am reverting to the status set by Harry, and tagging appropriately.

Thank you all for collaborating nicely as we are still discovering what we can (and can't) do on Launchpad.

I missed the conversation since the 21st, but I dived again into the problem today (started my holiday) and I think I've solved it.
The error was in the pkgconfig file.
Due to the way we need to build for older versions of the OS, and due to the way that building statically is highly discouraged on OSX we need to do some tricks to make it work. "Something" changed going from Leopard (10.5) to Snow Leopard (10.6) causing the pkgconfig pc file failing for static builds.

Note: It's not in enblend's/enfuse's configure and as such absolutely not an enblend/enfuse bug.

Mac users on Tiger following launchpad: Please download the new Tiger static builds from <http://harryvanderwolf.dyndns.org/Hugin/tmp/enblend-enfuse-4.0-Tiger.zip> and test whether HDR (.hdr and .exr) are now supported. Hopefully we can include a fixed build in the final Hugin 2010.4.0.

I will post a separate mail via hugin-ptx as I think the audience is bigger there.

Sorry for the inacurate comment. With the pkgconfig file I meant the OpenEXR.pc file.

On December 24, 2010 09:51:07 am hvdwolf wrote:
> Note: It's not in enblend's/enfuse's configure and as such absolutely
> not an enblend/enfuse bug.

The tracker is a list of things to do. Some of them are code bugs, others,
like this one, are build and distribution issues. Some of them we can fix,
others we can't. I thank you very much for taking care of all the OSX
details, else we'd have to declare them "won't fix" for lack of knowledge,
skill, resources, time.

> I will post a separate mail via hugin-ptx as I think the audience is
> bigger there.

Well done. Advertise where the audience is bigger. Try to make sure that the
relevant info is collected in the tracker, ideally entered directly by the
user.

Thank you, Harry.

Yuv