[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: [PATCH] Re: Weird kdelibs/kfile compile problem
From:       Gordon Sadler <gbsadler1 () lcisp ! com>
Date:       2001-05-15 15:07:58
[Download RAW message or body]

On Tue, May 15, 2001 at 10:35:08AM -0400, Rob Napier wrote:
> On Tue, May 15, 2001 at 10:46:51AM +0200, Stephan Kulow wrote:
> > On Tuesday 15 May 2001 01:46, Rob Napier wrote:
> > > On Wed, May 09, 2001 at 12:08:28PM +0200, Stephan Kulow wrote:
> > > > > The below patch seems to make Solaris happy (there are other compiling
> > > > > problems right now). I wouldn't think it would cause trouble for
> > > > > anyone else. Does it?
> > > >
> > > > You mean like people not using gcc?
> > >
> > > Is -isystem gcc specific? I seem to be in a minefield here, and I
> > > can't figure out what changed. for instance, here's today's latest
> > > problem:
> > >
> > > g++ -DHAVE_CONFIG_H -I. -I. -I.. -I../dcop -I../libltdl -I../kdecore
> > > -I../kdeui -I../kssl -I/users/rnapier/qt2/include -I/usr/openwin/include
> > > -I/users/rnapier/kde2/include -I/usr/local/include
> > > -I/usr/local/contrib/include -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS
> > > -DUSE_SOLARIS -O2 -fno-exceptions -fno-check-new -frtti -ftemplate-depth-99
> > > -DQT_NO_TRANSLATION -DQT_CLEAN_NAMESPACE -DQT_NO_COMPAT -DQT_NO_ASCII_CAST
> > > -Wp,-MD,.deps/ksocks.pp -c ksocks.cpp  -fPIC -DPIC -o .libs/ksocks.o
> > > ksocks.cpp: In method `int KSocks::connect(int, const sockaddr *, unsigned
> > > int)': ksocks.cpp:432: passing `const sockaddr *' as argument 2 of
> > > `connect(int, sockaddr *, int)' discards qualifiers ksocks.cpp: In method
> > > `int KSocks::recvfrom(int, void *, long unsigned int, int, sockaddr *,
> > > ksocklen_t *)': ksocks.cpp:456: ANSI C++ forbids implicit conversion from
> > > `void *' in argument passing ksocks.cpp: In method `int KSocks::sendto(int,
> > > const void *, long unsigned int, int, const sockaddr *, unsigned int)':
> > > ksocks.cpp:467: ANSI C++ forbids implicit conversion from `void *' in
> > > argument passing ksocks.cpp: In method `int KSocks::recv(int, void *, long
> > > unsigned int, int)': ksocks.cpp:474: ANSI C++ forbids implicit conversion
> > > from `void *' in argument passing ksocks.cpp: In method `int
> > > KSocks::send(int, const void *, long unsigned int, int)': ksocks.cpp:481:
> > > ANSI C++ forbids implicit conversion from `void *' in argument passing
> > > make[1]: *** [ksocks.lo] Error 1
> > > make[1]: Leaving directory `/users/rnapier/kde-cvs/kdelibs/kdecore'
> > > make: *** [all-recursive] Error 1
> > >
> > >
> > > I've also tried it with -isystem /usr/openwin/include to no avail. A
> > > couple of weeks ago, I got these warnings, but they weren't errors. I
> > > can't find a -Werror or -pedantic-errors anywhere. This warning->error
> > > translation was why I went down the road of using -isystem.
> > >
> > > The only thing that seems to fix this is to put in -fpermissive. Did
> > > that use to be in there and get removed? Is there something less
> > > drastic that could fix this?
> > >
> > We used to use -pedantic, which gives you a lot of warnings. Now we don't use 
> > it anymore, so you now get _some_ errors. -fpermissive has been added for 
> > Solaris, so I wouldn't mind adding it there :)
> > But -pedantic would help _you_ too.
> 
> Not sure I understand here. I'm running solaris (2.6). Do you mean
> -fpermissive was just added?
> 
> I'm thrilled to get more warning-free code, but I'm not sure how we
> want to go about it. The common problem is that Linux uses void* for
> things Solaris uses char* for. Similarly, there's a lot of
> signed/unsigned problems floating around. I remember the nightmare of
> getting size_t/socklen_t finally all working. Do we have the stomach
> for more of that? Do we have a "normal" way of going about fixing it?
> I'm happy to start sending examples.
> 
> Here's my biggest one currently:
> 
> /usr/openwin/include/X11/Xutil.h:363: ANSI C++ forbids declaration `XClipBox' with no type
> 
> I get dozens of these whenever Xutil.h is included. Changing '-I
> /usr/openwin/include' to '-isystem /usr/openwin/include' fixes it, but
> often breaks other things that use $(INCLUDES) like mcopidl. I don't
> deeply understand what -isystem does, unfortunately. The gcc info
> section on it is extremely vague.
> 
Just for reference from cpp.info (gcc-3_0-branch):
System Headers
--------------

   The header files declaring interfaces to the operating system and
   runtime libraries often cannot be written in strictly conforming C.
   Therefore, GNU C gives code found in "system headers" special
   treatment.  Certain categories of warnings are suppressed, notably those
   enabled by `-pedantic'.

   Normally, only the headers found in specific directories are
   considered system headers.  The set of these directories is determined
   when GCC is compiled.  There are, however, two ways to add to the set.

   The `-isystem' command line option adds its argument to the list of
   directories to search for headers, just like `-I'.  In addition, any
   headers found in that directory will be considered system headers.
   Note that unlike `-I', you must put a space between `-isystem' and its
   argument.

   All directories named by `-isystem' are searched *after* all
   directories named by `-I', no matter what their order was on the
   command line.  If the same directory is named by both `-I' and
   `-isystem', `-I' wins; it is as if the `-isystem' option had never been
   specified at all.

   There is also a directive, `#pragma GCC system_header', which tells
   GCC to consider the rest of the current include file a system header, no
   matter where it was found.  Code that comes before the `#pragma' in the
   file will not be affected.

   `#pragma GCC system_header' has no effect in the primary source file.

I cannot guarantee that gcc-2.95.x behaves exactly the same, as this isn't
documented in cpp.info from 2.95.3. But the first paragraph seems to
explain (eg. -pedantic).

HTH
-- 
Gordon Sadler

 
>> Visit http://master.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

[prev in list] [next in list] [prev in thread] [next in thread]