pkg/43577: graphics/ov519view graphics/cpia2view graphics/cnxtview all fail to compile with jpeg-8b (NetBSD 4.0/i386)

[kre%munnari.OZ.AU@localhost]

>Number:         43577
>Category:       pkg
>Synopsis:       graphics/ov519view graphics/cpia2view graphics/cnxtview all 
>fail to compile with jpeg-8b (NetBSD 4.0/i386)
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    pkg-manager
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Jul 07 11:05:00 +0000 2010
>Originator:     Robert Elz
>Release:        NetBSD 4.0 / i386   (pkgsrc current 2010-07-07)
>Organization:
        Prince of Songkla University
>Environment:
System: NetBSD jade.coe.psu.ac.th 4.0_STABLE NetBSD 4.0_STABLE 
(JADE-1.696-20080517) #9: Fri May 23 18:55:13 ICT 2008 
kre%jade.coe.psu.ac.th@localhost:/usr/obj/4/kernels/JADE i386
Architecture: i386
Machine: i386
>Description:
        It appears that jpeg-8b changed the prototype of the new
        function declaration added in jpeg8 (jpeg_mem_src) by altering
        the type of the 3rd arg from size_t (in jpeg-8) to unsigned long (8b).

        To me, that kind of API change looks like it should deserve a
        major version bump in the library, as those types are not necessarily
        even slightly compatible, but ...

        Because of that, the three packages (that I know of) that
        declare their own jpeg_mem_src() functions (which all broke
        when jpeg-8 appeared (see PRs 42698 42699 42700), have all
        broken again...

        This time just one PR (this) for all three of them, they are
                graphics/ov519view
                graphics/cpia2view
                graphics/cnxtview

        They're all ery similar source, and look to have a common origin,
        so I am assuming they will all be fixed together.


>How-To-Repeat:
        Pick any of the three, attempt to build it with jpeg-8b,
        and expect to see (something like) ...

#   compile  ov51x-1.65-1.11-mark/jpeg_decode.o
cc -O2 -I/usr/pkg/include -I/usr/include -Wall -I/usr/pkg/include/gtk-1.2 
-I/usr/pkg/include/glib/glib-1.2 -I/usr/pkg/lib/glib/include 
-I/usr/pkg/include/gtk-1.2 -I/usr/pkg/include/glib/glib-1.2 
-I/usr/pkg/lib/glib/include -I/usr/pkg/include -I/usr/pkg/include 
-I/usr/pkg/include     -I/usr/pkg/include -I/usr/include    -c    jpeg_decode.c
jpeg_decode.c:86: error: conflicting types for 'jpeg_mem_src'
/pkg_comp/obj/pkgsrc/graphics/ov519view/4x/.buildlink/include/jpeglib.h:959: 
error: previous declaration of 'jpeg_mem_src' was here
*** Error code 1

Stop.
make: stopped in /pkg_comp/obj/pkgsrc/graphics/ov519view/4x/ov51x-1.65-1.11-mark
*** Error code 1

Stop.

        The conflicting types, as far as I could see, amounted entirely
        to the different 3rd arg in the prototype of the function (of course,
        I might also have just not spotted some other change...)

>Fix:
        Change these 3 to all use "unsigned long" as the 3rd arg type,
        instead of size_t (it's unlikely that will have any fallout, just
        changing the declaration - in each - should be sufficient).

        Then hope that the upstream idiots looking after graphics/jpeg
        don't do anything like this again...   (it is actually surprising,
        after so many years of jpeg6 being so good, that they'd mess up
        this badly).