libpng-1.4.0 TO DO

[Glenn Randers-Pehrson]

Before putting out libpng-1.4.0rc01, we should address a few issues.

1) The makefiles and the configure script don't produce the same
fileset (the makefiles also produce libpng14.so.14.1.4.0beta86 as the
real file with libpng14.so and libpng.so.14 being symbolic links.

On a FreeBSD system, "make install" using makefile.linux produces

lrwxr-xr-x           10 Oct  9 10:58 libpng.a -> libpng14.a
lrwxr-xr-x           12 Oct  9 10:58 libpng.so -> libpng.so.14
lrwxr-xr-x           24 Oct  9 10:58 libpng.so.14 -> libpng.so.14.1.4.0beta86
-rwxr-xr-x   127989 Oct  9 10:58 libpng.so.14.1.4.0beta86
-rw-r--r--    142812 Oct  9 10:58 libpng14.a
lrwxr-xr-x           14 Oct  9 10:58 libpng14.so -> libpng14.so.14
lrwxr-xr-x           26 Oct  9 10:58 libpng14.so.14 ->
libpng14.so.14.1.4.0beta86
-rwxr-xr-x  127989 Oct  9 10:58 libpng14.so.14.1.4.0beta86
drwxr-xr-x           4 Oct  9 10:58 pkgconfig

"configure; make install" produces
llrwxr-xr-x      10 Oct  9 10:51 libpng.a -> libpng14.a
lrwxr-xr-x      11 Oct  9 10:51 libpng.la -> libpng14.la
lrwxr-xr-x      11 Oct  9 10:51 libpng.so -> libpng14.so
-rwxr-xr-x  449581 Oct  9 10:51 libpng.so.14
-rw-r--r--   617140 Oct  9 10:51 libpng14.a
-rwxr-xr-x     957 Oct  9 10:51 libpng14.la
lrwxr-xr-x      14 Oct  9 10:51 libpng14.so -> libpng14.so.14
-rwxr-xr-x  440509 Oct  9 10:51 libpng14.so.14
drwxr-xr-x       4 Oct  9 10:51 pkgconfig

There seems to be no way to coerce "configure" into
producing  libpng14.so.14.1.4.0beta86 and
libpng.so.14.1.4.0beta86  so I suppose the best approach
is to revise the makefiles to not make them either.

The libpng-config and libpng14-config are identical to
each other, but different from the corresponding ones
in configure and makefile-built directories.  I think
libpng-config should contain information about libpng
and not about libpng14.

It is interesting to note how much larger the configure-built
libraries are.  It's not surprising that the finely-tuned
makefiles might produce better libraries, though.

2) fast integer gamma tables.  Since no one seems to be
working on that, I suppose it can wait until 1.4.1

3) interpolated display of interlaced files.  That too can
wait until a later release.

4) Did we ever resolve the business about linking zlib
into the shared libraries?  Are the configure-built libraries
and the makefile-built libraries alike in this respect?  I
suspect that they are different.

Glenn

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
png-mng-implement mailing list
png-mng-implement@...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement

[Cosmin Truta]

On Fri, Oct 9, 2009 at 12:34 PM, Glenn Randers-Pehrson wrote:

> Before putting out libpng-1.4.0rc01, we should address a few issues.

I agree with 1,2,3,4, and do not forget about 5 :-)

> 1) The makefiles and the configure script don't produce the same
> fileset [...]

I agree, it's good to have this sorted out before the final release.
At least, it's good to be sure there isn't something that turns out to
be impossible to remove later on, due to interfacing/compatibility
issues.

> It is interesting to note how much larger the configure-built
> libraries are.  It's not surprising that the finely-tuned
> makefiles might produce better libraries, though.

The differences between the output produced by the custom makefile vs.
the configure'd makefile are too big (120k vs. 440k) to assume they
are caused by fine tuning. I'd rather think something as big as debug
symbols, or maybe a whole library (zlib? libc?) is statically linked
in the configure'd libpng.

> 2) fast integer gamma tables.  Since no one seems to be
> working on that, I suppose it can wait until 1.4.1
>
> 3) interpolated display of interlaced files.  That too can
> wait until a later release.

Agreed.

> 4) Did we ever resolve the business about linking zlib
> into the shared libraries?  Are the configure-built libraries
> and the makefile-built libraries alike in this respect?  I
> suspect that they are different.

Maybe this is what causes that big difference in (1).


And finally, let us not forget...

5) As we discussed earlier, I would still like to see pre-ANSI
artifacts like _NO_PROTO/PNGARG, PNG_CONST, png_sizeof, png_FILE_p
(and maybe others) removed, before libpng-1.4.0 is released.


Best regards,
Cosmin

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
png-mng-implement mailing list
png-mng-implement@...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement

[Glenn Randers-Pehrson]

On Fri, Oct 9, 2009 at 6:31 PM, Cosmin Truta <cosmin@...> wrote:

> The differences between the output produced by the custom makefile vs.
> the configure'd makefile are too big (120k vs. 440k) to assume they
> are caused by fine tuning. I'd rather think something as big as debug
> symbols, or maybe a whole library (zlib? libc?) is statically linked
> in the configure'd libpng.

The same situation exists with libpng-1.2.41beta05.

"size -t *.a" gives no indication that either contains anything but
libpng object files.  I suppose the difference could be explained by
the presence or absence of debug symbols.

"strip *.a" reverses the size disparity: the "config" generated libpng12.a
becomes about 124k while the "makefile" generated one is only reduced
to about 226k.

shaggy.simplesystems.org> ls -l *.a
lrwxr-xr-x  1 glennrp  visitor      10 Oct 10 11:31 libpng.a -> libpng12.a
-rw-r--r--  1 glennrp  visitor  279584 Oct 10 11:31 libpng12.a
shaggy.simplesystems.org> strip libpng12.a
shaggy.simplesystems.org> ls -l *.a
lrwxr-xr-x  1 glennrp  visitor      10 Oct 10 11:31 libpng.a -> libpng12.a
-rw-r--r--  1 glennrp  visitor  226172 Oct 10 11:45 libpng12.a
shaggy.simplesystems.org> cd ../../lp1241b05-*con*/lib
shaggy.simplesystems.org> ls -l *.a
lrwxr-xr-x  1 glennrp  visitor      10 Oct 10 11:33 libpng.a -> libpng12.a
-rw-r--r--  1 glennrp  visitor  629220 Oct 10 11:33 libpng12.a
shaggy.simplesystems.org> strip libpng12.a
shaggy.simplesystems.org> ls -l *.a
lrwxr-xr-x  1 glennrp  visitor      10 Oct 10 11:33 libpng.a -> libpng12.a
-rw-r--r--  1 glennrp  visitor  123612 Oct 10 11:45 libpng12.a

shaggy.simplesystems.org> size -t *12.a
   text    data     bss     dec     hex filename
   5905     105       0    6010    177a libpng12_la-png.o (ex libpng12.a)
   6657       0       0    6657    1a01 libpng12_la-pngset.o (ex libpng12.a)
   3178       0       0    3178     c6a libpng12_la-pngget.o (ex libpng12.a)
  20249       0       0   20249    4f19 libpng12_la-pngrutil.o (ex libpng12.a)
   2417       0       0    2417     971 libpng12_la-pngtrans.o (ex libpng12.a)
  16718       0       0   16718    414e libpng12_la-pngwutil.o (ex libpng12.a)
   8958       0       0    8958    22fe libpng12_la-pngread.o (ex libpng12.a)
    399       0       0     399     18f libpng12_la-pngrio.o (ex libpng12.a)
    472       0       0     472     1d8 libpng12_la-pngwio.o (ex libpng12.a)
   8928       0       0    8928    22e0 libpng12_la-pngwrite.o (ex libpng12.a)
  26029       0       0   26029    65ad libpng12_la-pngrtran.o (ex libpng12.a)
   2529       0       0    2529     9e1 libpng12_la-pngwtran.o (ex libpng12.a)
    770       0       0     770     302 libpng12_la-pngmem.o (ex libpng12.a)
   1332       0       0    1332     534 libpng12_la-pngerror.o (ex libpng12.a)
   8865       0       0    8865    22a1 libpng12_la-pngpread.o (ex libpng12.a)
 113406     105       0  113511   1bb67 (TOTALS)

Glenn

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
png-mng-implement mailing list
png-mng-implement@...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement

[Glenn Randers-Pehrson]

makefile.elf produces about the same sizes as configure:

   text    data     bss     dec     hex filename
   5905     105       0    6010    177a png.o (ex libpng12.a)
   6657       0       0    6657    1a01 pngset.o (ex libpng12.a)
   3178       0       0    3178     c6a pngget.o (ex libpng12.a)
  20249       0       0   20249    4f19 pngrutil.o (ex libpng12.a)
   2417       0       0    2417     971 pngtrans.o (ex libpng12.a)
  16718       0       0   16718    414e pngwutil.o (ex libpng12.a)
   8958       0       0    8958    22fe pngread.o (ex libpng12.a)
    399       0       0     399     18f pngrio.o (ex libpng12.a)
    472       0       0     472     1d8 pngwio.o (ex libpng12.a)
   8928       0       0    8928    22e0 pngwrite.o (ex libpng12.a)
  26029       0       0   26029    65ad pngrtran.o (ex libpng12.a)
   2529       0       0    2529     9e1 pngwtran.o (ex libpng12.a)
    770       0       0     770     302 pngmem.o (ex libpng12.a)
   1332       0       0    1332     534 pngerror.o (ex libpng12.a)
   8865       0       0    8865    22a1 pngpread.o (ex libpng12.a)
 113406     105       0  113511   1bb67 (TOTALS)

The difference (after stripping) is entirely explained by the use of
the "-O3 -funroll-loops" versus the "-O2" compiler options.

Therefore it does not seem to be something that needs
to be fixed before rolling out libpng-1.4.0.

Glenn
~

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
png-mng-implement mailing list
png-mng-implement@...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement

[Cosmin Truta]

Glenn Randers-Pehrson wrote:

> "size -t *.a" gives no indication that either contains anything but
> libpng object files.  I suppose the difference could be explained by
> the presence or absence of debug symbols.
>
> "strip *.a" reverses the size disparity: the "config" generated libpng12.a
> becomes about 124k while the "makefile" generated one is only reduced
> to about 226k.

That could be it, then: differences in optimization levels, and debug symbols.
I see -g commented away in script/makefile.*, but -g does show up in
the configure'd build.

> Therefore it does not seem to be something that needs
> to be fixed before rolling out libpng-1.4.0.

I'm also glad that the mystery is solved :-)

I never knew which is the right way to go when installing something in
the system: with debug symbols (such that debugging of user
applications is easier)? or without debug symbols (such that disk
space is economized)? The difference in size is significant, in my
experience, the debug-enabled build is at least twice as big. By
default, OptiPNG's build scripts strip the debug symbols, but some
package builders choose to override the defaults and keep those
symbols in.

Best regards,
Cosmin

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
png-mng-implement mailing list
png-mng-implement@...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement

[Bob Friesenhahn]

On Sat, 10 Oct 2009, Glenn Randers-Pehrson wrote:
>
> The difference (after stripping) is entirely explained by the use of
> the "-O3 -funroll-loops" versus the "-O2" compiler options.

You might want to examine the optimization options used.  Use of -O3
was often beneficial with anchient GCC but with modern GCC I am
finding that it often causes harm to performance.  All the "good
stuff" seems to be included with -O2 now.  Larger code is  not
necessarily faster.

Bob
--
Bob Friesenhahn
bfriesen@..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
png-mng-implement mailing list
png-mng-implement@...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement

[John Bowler]

From: Bob Friesenhahn [mailto:bfriesen@...]
>You might want to examine the optimization options used.  Use of -O3
>was often beneficial with anchient GCC but with modern GCC I am
>finding that it often causes harm to performance.  All the "good
>stuff" seems to be included with -O2 now.  Larger code is  not
>necessarily faster.

I second that, it's an ancient x86 thing caused by fast code load combined
with slow branch operation.  It was defeated by modern instruction caches -
even x86 has those these days ;-)

I find -Os to be best on gcc - it is -O2 with optimizations to reduce code
size.  (That is, it does everything -O2 does with only those O3
optimizations which do reduce the code size.)  There are similar
optimizations for Visual C, but I can no longer remember what they are.

John Bowler <jbowler@...>


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
png-mng-implement mailing list
png-mng-implement@...
https://lists.sourceforge.net/lists/listinfo/png-mng-implement