[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: pkg/40198 (www/amaya compile errors (modular xorg, NetBSD 4.0) .. again)
The following reply was made to PR pkg/40198; it has been noted by GNATS.
From: Robert Elz <kre%munnari.OZ.AU@localhost>
Subject: Re: pkg/40198 (www/amaya compile errors (modular xorg, NetBSD 4.0) ..
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>
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
| 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
-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
../../thotlib/dialogue/base64.cpp:120: error: ISO C++ forbids declaration of
'wxBase64DecInputStream' with no type
../../thotlib/dialogue/base64.cpp: In function 'int
../../thotlib/dialogue/base64.cpp:120: error: only constructors take base
../../thotlib/dialogue/base64.cpp:127: error: 'm_out' was not declared in this
../../thotlib/dialogue/base64.cpp:128: error: 'm_in' was not declared in this
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 ...
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
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
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.
Main Index |
Thread Index |