From kde-solaris  Wed Jun 19 14:59:11 2002
From: Eva Brucherseifer <eva () kde ! org>
Date: Wed, 19 Jun 2002 14:59:11 +0000
To: kde-solaris
Subject: Re: [kde-solaris] Fwd: Bug#44096: One system include file (net/if.h) conflicts with g++ include stl_
X-MARC-Message: https://marc.info/?l=kde-solaris&m=102450258520983


> Anyone?
>
> ----------  On Wednesday 19 June 2002 11:00, bmarcade@canal-plus.fr wrote:
> ----------
>
> Subject: Bug#44096: One system include file (net/if.h) conflicts with g++
> include stl_map.h
> Date: Wednesday 19 June 2002 11:00
> From: bmarcade@canal-plus.fr
> To: submit@bugs.kde.org
>
> Package: kcontrol
> Version: kde-base 3.0 kcontrol/nics (using KDE 3.0.1 )
> Severity: normal
> Installed from:    Compiled From Sources
> Compiler:          gcc 2.95.3
> OS:                Solaris
> OS/Compiler notes: Solaris 2.6 and gcc2.95.3 rebuild with --enable-shared
> Problem occurs when building kdebase-3.0, when entering kcontrol/nics. Fi=
le
>  nic.cpp include various files of which /usr/include/net/if.h (system
> include from Solaris 2.6) and sl_map.h (delivered with gcc-2.95.3). System
> include file (net/if.h) conflicts with gcc include files (stl_map.h). File
> (net/if.h) contains a structure named 'map' and stl_map.h a class named
> 'map'. As both are included when building kdebase/kcontrol/nics/nic.cpp,
> gcc returns an error message. A simple fix is to comment line 'struct map
> *ifconf' within net/if.h. Build achieves correctly. Same issue exists
> within kdebase-3.0/kdm/chooser, fixed with same solution. (Submitted via
> bugs.kde.org)
> (Complete bug history is available at http://bugs.kde.org/db/44/44096.htm=
l)
>
> -------------------------------------------------------

In the sources there is something like a fix, but it doesn't look very nice:
#ifdef USE_SOLARIS
/* net/if.h is incompatible with STL on Solaris 2.6 - 2.8, redefine
   map in the header file because we don't need it. -- Simon Josefsson */
#define map junkmap
#endif
#  include <net/if.h>
#ifdef USE_SOLARIS
#undef map
#endif

Matze told me, that USE_SOLARIS is set by libtool - so maybe this guy has a=
=20
problem with libtool? Maybe his perl version is tool old?

In the sources I couldn't find the place where stl_map.h is included - is i=
t=20
really stl_map.h directly? I hope not. It acutally should be <map>.=20
In the sources quite often the old way of including standard headers is use=
d.=20
Is there any particular reason to do so? The ANSI standard was made in 1998=
=20
so I think it's time to do it standard conform...

Just to be clear - the old way is
   #include <stdlib.h>
   #include <iostream.h>

The new way is=20
  #include <cstdlib>
  #include <iostream>
  using namespace std;

Instead of switching to the std namespace completly one also can (or should=
)=20
use std:: to address all standard classes/functions/etc. Maybe that also=20
helps here.

On Solaris8 and using gcc3.1 we didn't have the problem, it compiled all wa=
y=20
through. But also the compiler seems to include the new headers instead of=
=20
the old headers (we found a bug in cmath where math.h was included in the=20
source file...).

The if.h looks like this on Solaris 7 and 8. Don't know of the Solaris 6=20
version is different:

struct ifnet {
  ... lots of other elements ...
        struct map *if_memmap;          /* rmap for interface specific memo=
ry=20
*/
};

So far,
eva

___________________________________________________
This message is from the kde-solaris mailing list.
Account management:  http://mail.kde.org/mailman/listinfo/kde-solaris.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.