Re: pkg/40198 (www/amaya compile errors (modular xorg, NetBSD 4.0) .. again)

[Robert Elz <kre%munnari.OZ.AU@localhost>]

The following reply was made to PR pkg/40198; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: pkg/40198 (www/amaya compile errors (modular xorg, NetBSD 4.0) .. 
again)
Date: Wed, 17 Aug 2011 16:16:38 +0700

     Date:        Tue, 16 Aug 2011 01:05:03 +0000 (UTC)
     From:        David Holland <dholland-pbugs%NetBSD.org@localhost>
     Message-ID:  <20110816010503.6874763B89A%www.NetBSD.org@localhost>
 
 On Mon, Aug 15, 2011 at 02:15:05PM +0000, I wrote:
   >  Leave this in feedback state for now ... the error with intptr_t
   >  is gone, but is just replaced by a whole different set
 
 In reply ... From: David Holland <dholland-pbugs%netbsd.org@localhost>
   | Subject: Re: pkg/40198 (www/amaya compile errors (modular xorg, NetBSD 4.0)
   |  .. again)
   | Date: Tue, 16 Aug 2011 01:00:03 +0000
 
   |  ok.
   |  
   |  I'm not sure it's worth spending any time on this pile...
 
 No, and if someone were to mark it BROKEN or simply cvs rm it, I wouldn't
 be complaining, but as long as it continues to pretend it should be usable,
 we can probably afford a little time in figuring out why it isn't.
 
 The errors I'm seeing this time (start out as) ...
 
 c++ -O2 -Dunix -fno-strict-aliasing -I/usr/pkg/include -I/usr/include 
-I/usr/include/krb5 -I/usr/pkg/include/freetype2 -Wall -x c++ -D__cplusplus 
-D_UNIX -D_GL -D_WX -DHAVE_CONFIG_H -I.. -I../../amaya/xpm 
-I../../thotlib/include -I../../thotlib/internals/var 
-I../../thotlib/internals/h -I../../thotlib/internals/f   
-I/usr/pkg/lib/wx/include/gtk2-unicode-release-2.8 -I/usr/pkg/include/wx-2.8 
-D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -pthread -I/usr/include   
-I/usr/pkg/include/freetype2 -I/usr/pkg/include  -c 
../../thotlib/dialogue/base64.cpp -o dialogue/base64.o
 ../../thotlib/dialogue/base64.cpp:120: error: 'wxBase64DecInputStream' has not 
been declared
 ../../thotlib/dialogue/base64.cpp:120: error: ISO C++ forbids declaration of 
'wxBase64DecInputStream' with no type
 ../../thotlib/dialogue/base64.cpp: In function 'int 
wxBase64DecInputStream(wxInputStream&)':
 ../../thotlib/dialogue/base64.cpp:120: error: only constructors take base 
initializers
 ../../thotlib/dialogue/base64.cpp:127: error: 'm_out' was not declared in this 
scope
 ../../thotlib/dialogue/base64.cpp:128: error: 'm_in' was not declared in this 
scope
 
 
 There are actually a lot of errors of similar natures from this same file,
 that I'm not including here, as I think I understand the immediate cause of
 this problem, if not the underlying problem.
 
 base64.cpp includes ...
 
        #include "base64.h"
 
 and in ../include/base64.h there is what looks to be a perfectly adequate
 definition of a wxBase64DecInputStream class, with members including m_out
 and m_in (and others that deleted error messages claim are missing.)
 
 The file is protected by (two) #ifder's, but one of those looks to just
 be the typical double include protection, which shouldn't be causing the
 file content to be ignored, and the other is also present in base64.cpp
 (the file wouldn't be being compiled at all, other than as an empty source
 file, if the symbol wasn't defined).
 
 But clearly something is causing that base64.h file (or its contents) to be
 ignored, so I looked through the sequence of the -I directives on the
 command line, and found that
 
        /usr/include/krb5/base64.h
 
 exists (on NetBSD 4 anyway - it appears to be there on NetBSD 5 as well)
 and contains nothing that would be useful to this base64.cpp file.
 
 Namespace pollution (of a slightly different kind than we normally see.)
 
 A simple fix would be to change the #include in base64.cpp to be
 #include "../include/base64.h" and that seems to avoid the problem
 (only seems, as I don't think this is the right fix, and so didn't
 really do the compile properly to verify it - just enough to see that
 these errors didn't occur and that it seemed to have reached beyond the
 point where they would.)
 
 Rather, I cannot imagine why anything (with the outside possible
 exception of very kerberos code - and really not even there) should
 ever do
        -I /usr/include/krb5
 
 Rather, whenever one of those files needs to be included, it should be
 included as <krb5/filename,h> and obtained via (-I /usr/include) most
 probably via the default cc include path - I also have no idea why
 this thing's build needs explicit -I /usr/include - that suggests code
 bugs to me).
 
 So, first step in making progress on this would seem to be to work out what's
 adding that weird -I flag, and nuke it, and if that causes other build
 problems, fix those by patching the #include lines as needed.
 
 That should get us past this particular build failure, and onto the next one!
 
 If no-one else (eg; dholland...) makes any progress on this before the
 next time I have some time to spare for it, I'll take a look at figuring
 out what is adding that -I and see if I can make it go away.   Not today.
 
 kre