enblend build breakage with latest libpng

[Greg 'groggy' Lehey]

I've just tried to build enblend 4.0 with the latest release of
libpng. It fails:

g++46 -DHAVE_CONFIG_H -I. -I../.. -I/usr/local/include -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -I../../include -DVIGRA_STATIC_LIB -D_THREAD_SAFE -I/usr/local/include/OpenEXR -O2 -pipe -Wl,-rpath=/usr/local/lib/gcc46 -fno-strict-aliasing --param inline-unit-growth=60 -O2 -DNDEBUG -Wall -MT libvigra_impex_a-png.o -MD -MP -MF .deps/libvigra_impex_a-png.Tpo -c -o libvigra_impex_a-png.o `test -f 'png.cxx' || echo './'`png.cxx
png.cxx: In function 'void PngError(png_structp, png_const_charp)':
png.cxx:84:21: error: invalid use of incomplete type 'png_struct {aka struct png_struct_def}'
/usr/local/include/png.h:872:16: error: forward declaration of 'png_struct {aka struct png_struct_def}'
png.cxx: In constructor 'vigra::PngDecoderImpl::PngDecoderImpl(const string&)':
(many more such messages follow)

This seems to be a deliberate decision on the part of the authors of
libpng. At http://www.libpng.org/pub/png/libpng.html there's a
notice:

Portability Note

The libpng 1.5.x series continues the evolution of the libpng API,
finally hiding the contents of the venerable and hoary png_struct
and png_info data structures inside private (i.e., non-installed)
header files. Instead of direct struct-access, applications should
be using the various png_get_xxx() and png_set_xxx() accessor
functions, which have existed for almost as long as libpng
itself. (Apps that compiled against libpng 1.4 without warnings
about deprecated features should happily compile against 1.5,
too.)

I haven't found any mention of this problem on this mailing list. The
only thing I found is
https://groups.google.com/forum/?fromgroups#!searchin/hugin-ptx/enblend$20png_struct|sort:date/hugin-ptx/lvPmeMxAO7w/O7ZuINL0shQJ
(is there really no way of getting a shorter link?), referring to 1.4
and the "deprecated" warnings. Has anybody done anything about this?
Otherwise I'll have a go. I don't see reverting to libpng 1.4 as a
solution.

Greg
--
Sent from my desktop computer.
Finger gr...@FreeBSD.org for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed. If your Microsoft MUA reports
problems, please read http://tinyurl.com/broken-mua

[Lukáš Jirkovský]

You can use libpng patches from Arch Linux:
https://projects.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/enblend-enfuse

There are both patches for 1.4 compatibility and 1.5 compatibility.

Lukas

[Greg 'groggy' Lehey]

On Sunday, 15 July 2012 at 8:43:01 +0200, Luk?? Jirkovsk wrote:
> On 15 July 2012 04:10, Greg 'groggy' Lehey <groo...@gmail.com> wrote:
>> I've just tried to build enblend 4.0 with the latest release of
>> libpng. It fails:
>>

>> ...

>>
>> I haven't found any mention of this problem on this mailing list. The
>> only thing I found is
>> https://groups.google.com/forum/?fromgroups#!searchin/hugin-ptx/enblend$20png_struct|sort:date/hugin-ptx/lvPmeMxAO7w/O7ZuINL0shQJ
>> (is there really no way of getting a shorter link?), referring to 1.4
>> and the "deprecated" warnings. Has anybody done anything about this?
>> Otherwise I'll have a go. I don't see reverting to libpng 1.4 as a
>> solution.
>
> You can use libpng patches from Arch Linux:
>
> https://projects.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/enblend-enfuse

Thanks. I don't have time to try them now, but the patch for 1.5
looks exactly like what I would expect. Is anybody working on getting
them into the enblend/enfuse repository?

> There are both patches for 1.4 compatibility and 1.5 compatibility.

Yes, I know the 1.4 patch. It's in the FreeBSD Ports Collection. I'm
surprised that this isn't in the 1.5 patch; maybe they both need to be
applied.

[Lukáš Jirkovský]

On 15 July 2012 09:03, Greg 'groggy' Lehey <groo...@gmail.com> wrote:
>
> Thanks. I don't have time to try them now, but the patch for 1.5
> looks exactly like what I would expect. Is anybody working on getting
> them into the enblend/enfuse repository?
>

The fixes are already in the repository for more than a year, but a
new version was not released yet (IIRC because of some artifacts that
were not present with 4.0).

Lukas

[Tduell]

Greg,

On Sunday, July 15, 2012 5:16:43 PM UTC+10, stativ wrote:

On 15 July 2012 09:03, Greg 'groggy' Lehey  wrote: 
>
> Thanks.  I don't have time to try them now, but the patch for 1.5
> looks exactly like what I would expect.  Is anybody working on getting
> them into the enblend/enfuse repository?
>

The fixes are already in the repository for more than a year, but a
new version was not released yet (IIRC because of some artifacts that
were not present with 4.0).

Have you had any joy with building enblend 4 on your x86_64 system?

I had tried to build the current source (4.1), hoping to do a bit of testing, but ran into problems using cmake, and wondered if you have been using cmake with v4.0 and how it was working for you.

Cheers,

Terry

 

[Lukáš Jirkovský]

In case of 4.0 I'm using distribution packages (it's easier in Arch
Linux, because enblend needs to be rebuild quite often due to boost
updates), which use old-style configure. In case of the version from
mercurial it doesn't build for me right now. It uses boost::filesystem
v2 which has been removed from the newest boost (I'll port the code to
v3 ASAP). However I don't have any problems with the CMake itself.

Lukas

[Lukáš Jirkovský]

Oh, the support is already here. I just forgot that I added
-DBOOST_FILESYSTEM_VERSION=2 some time ago.

So no, I don't have any problems building enblend using CMake.

Lukas

[Tduell]

Hello Lukas,

On Sunday, July 22, 2012 4:47:25 PM UTC+10, stativ wrote:

[snip] 

In case of 4.0 I'm using distribution packages (it's easier in Arch 

Linux, because enblend needs to be rebuild quite often due to boost 

updates), which use old-style configure. In case of the version from
mercurial it doesn't build for me right now. It uses boost::filesystem
v2 which has been removed from the newest boost (I'll port the code to
v3 ASAP). However I don't have any problems with the CMake itself.

OK, then something might be wrong with my local copy of the Enblend source.

I'll set up a new copy and start again.

Cheers,

Terry

 

[Greg 'groggy' Lehey]

On Saturday, 21 July 2012 at 22:36:27 -0700, Tduell wrote:
> Greg,
>
> On Sunday, July 15, 2012 5:16:43 PM UTC+10, stativ wrote:
>>
>> On 15 July 2012 09:03, Greg 'groggy' Lehey wrote:
>>>
>>> Thanks. I don't have time to try them now, but the patch for 1.5
>>> looks exactly like what I would expect. Is anybody working on getting
>>> them into the enblend/enfuse repository?
>>
>> The fixes are already in the repository for more than a year, but a
>> new version was not released yet (IIRC because of some artifacts that
>> were not present with 4.0).
>>
> Have you had any joy with building enblend 4 on your x86_64 system?

Yes, it's working fine now, and it has eliminated some artefacts I saw
with enblend 3.1.

> I had tried to build the current source (4.1), hoping to do a bit of
> testing, but ran into problems using cmake, and wondered if you have
> been using cmake with v4.0 and how it was working for you.

This was 4.0, and if I understand Lukàs' messages correctly, things
have changed since then. I used GNU make, not cmake.

[Lukas Jirkovsky]

On 22 July 2012 09:52, Greg 'groggy' Lehey <groo...@gmail.com> wrote:
>
>> I had tried to build the current source (4.1), hoping to do a bit of
>> testing, but ran into problems using cmake, and wondered if you have
>> been using cmake with v4.0 and how it was working for you.
>
> This was 4.0, and if I understand Lukà s' messages correctly, things
> have changed since then. I used GNU make, not cmake.
>

No, not regarding the build system. Enblend supports both autoconf (ie
./configure && make) and CMake (ie. cmake . && make) configuration
since 4.0. You are free to choose which one you prefer.

Lukas

[Bruno Postle]

On Sun 22-Jul-2012 at 17:27 -0700, Terry Duell wrote:
>
>OK, then something might be wrong with my local copy of the Enblend source.
>I'll set up a new copy and start again.

enblend-enfuse from mercurial builds ok here using the autoconf
stuff.

I've put updated 4.1 snapshots for fedora in the panorama
repository: http://repos.fedorapeople.org/repos/bpostle/panorama/

BTW, for anyone using this repository for Hugin, it is soon going to
switch from snapshots of the gui_overhaul branch to the 2012.0
branch, i.e. the Hugin GUI will revert to the old interface, but
otherwise it should be fine.

--
Bruno