[tlbuild] Bug in libpng affecting Solaris 10

[Mojca Miklavec]

On 19 January 2016 at 02:28, Karl Berry wrote:
>         https://sourceforge.net/p/libpng/bugs/245/
>
> What a mess.
>
> How about compiling with gcc 4.9 (or any other working version)?

See also a similar thread:
    http://lists.gnu.org/archive/html/bug-wget/2015-12/msg00140.html

One citation from there (with the exception that I don't see any
_XOPEN_SOURCE definition in libpng):

> Seems pretty clear - gcc 5 has C99 as default standard (and Solaris has gcc
> 5.2).
> But we explicitely define _XOPEN_SOURCE 500 in src/sysdep.h, which says we
> want 'X/Open 5, POSIX 1995' functions and nothing newer.
> Solaris headers just make some checks to ensure proper definitions here and
> they fail.
>
> When I simply remove the define, everything compiles ok.
> The question is if we still want what the comment says: "/* Request the "Unix
> 98 compilation environment". */". I think, we should allow Wget to be compiled
> on newer environments as well.

--------------

> 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.)

I don't believe so. Based on the comments above the problems looks
like it's triggered by GCC 5 or later which defines C99 by default.

> 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.

I would really really like to avoid that. I'm afraid that means a lot
more pain than it is worth and I would only try to do it if there is
really no other workaround.

>     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 ...

I could try defining that globally, but I'm afraid that some other
package with perhaps more "modern requirements" could fail. Maybe I'm
just too paranoic though, so I should just try it out.

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

After others noted that it worked for them, I checked on Solaris 11 as
well and from what I remember (and wrote) it worked.

> 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.

It's not that they are not inclined to deal with this. More likely no
developer has access to Solaris 10. They might fix it if they get a
proper patch (defining -D_XOPEN_SOURCE is just a workaround in this
case, not a proper patch).

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

If you don't want to apply this to the sources, can you please at
least send me an attempt of a TeX Live-specific patch that does this?
I only need a patch that adds
    "-D_XOPEN_SOURCE=600 -D__EXTENSIONS__"
to CPPFLAGS when building libpng and nothing else (it doesn't have to
be specific to Solaris, but just enough that I can apply it locally
and test it). I'm not sure where these additional flags should
generally be defined.

> 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 ...

OK, give me some time and I'll try it.

(Ettore probably has more experience than I do. Ettore, if you are
willing to play with GCC 5.x a bit, that would be extremely helpful.
Esp. because this affects all architectures of Solaris.)

Thank you,
    Mojca