[tlbuild] Bug in libpng affecting Solaris 10

[Karl Berry]

        https://sourceforge.net/p/libpng/bugs/245/

What a mess.

How about compiling with gcc 4.9 (or any other working version)?  I too
have found places (dvisvgm...) where compiler version x on os version y
fails with package z.  My workaround has been to use different versions.

Also, gcc 5.3.0 is out.  Maybe it got fixed.  (Such a gratuitious
bombing out seems completely unnecessary to me in the first place.)

As for "how to change the version of the compiler", you can download the
gcc+library sources and build it yourself in your home directory.  I can
give you a (semi-)script if you want.  I know it's far from trivial, but
then, changing the build system is not trivial either.

    export CPPFLAGS="-D_XOPEN_SOURCE=600 -D__EXTENSIONS__"
    someone perhaps add these flags (only for libpng and only for Solaris)
    as a temporary workaround?

1) I don't recall anywhere else in the build tree that we have ever
added system-specific options for a particular package.  Am I forgetting
somewhere?  Probably ...

2) Apparently the problem is on "Solaris 5.10", rather than "Solaris",
from your last additions to the thread?

3) Apparently the libpng author is not inclined to deal with this, so
it's not clear that any such change would be temporary, which makes me
want to find some other solution.

4) These options have far-reaching effects.  Using them worries me.

5) The specifics of the original problem remain unclear to me.  Here's a
possible method for debugging further:

Take that gcc invocation as output by libtool, add -dD, redirect the
output to /tmp/foo, and run it (by hand) in the shell.  Then /tmp/foo
should have the result of preprocessing (up to the point of error),
including all the #defines as they are made.  Then it should be possible
to determine what is defining the problematic symbols, and then perhaps
there will be another way to avoid defining them in the first place.

It may be necessary to remove the 
  -MT png.lo -MD -MP -MF .deps/png.Tpo
from the invocation.  I'm not sure how all those dependency-generation
flags interact with -d.  The gcc manual claims it should be fine, I
think, but ...

    This will have to be fixed sooner or later in one way or another, so
    it might be better to address it now rather than in the last minute.

Indeed.  Thanks for bringing it up now.  -k