qnx6.1 & string.h

Hi Guys,

I have a weird problem using g++ - only since upgrading to 6.1
Initially I had lost ‘cvs’, so I did a full install of all new stuff on
the CD (e.g X server, PhAster, etc - I did a ‘full’ install to get
upgraded, but it seemed to have left a lot of it out).

Now, I get messages such as :

In file included from test.cpp:32:
/usr/include/string.h:155: ‘memcmp’ is already declared in this scope
/usr/include/string.h:155: ‘memcpy’ is already declared in this scope
/usr/include/string.h:156: ‘strcmp’ is already declared in this scope
/usr/include/string.h:156: ‘strcpy’ is already declared in this scope
/usr/include/string.h:156: ‘strlen’ is already declared in this scope

but it seems like a larger problem is with ‘cc’

e.g. ‘cc f.c’ gives me ‘invalid pre-processing directive name’
and '/usr/lib/gcc-lib/ntox86/2.95.2/cpp error 33
:1: invalid #-line

(my top line of f.c is #include <stdlib.h>)

Is this par for the course, or has my installation botched somewhere?

cheers
Lance

Hi Lance,

Lance Roberts <lance@econz.co.nz> wrote:

Hi Guys,

I have a weird problem using g++ - only since upgrading to 6.1
Initially I had lost ‘cvs’, so I did a full install of all new stuff on
the CD (e.g X server, PhAster, etc - I did a ‘full’ install to get
upgraded, but it seemed to have left a lot of it out).

Now, I get messages such as :

In file included from test.cpp:32:
/usr/include/string.h:155: ‘memcmp’ is already declared in this scope
/usr/include/string.h:155: ‘memcpy’ is already declared in this scope
/usr/include/string.h:156: ‘strcmp’ is already declared in this scope
/usr/include/string.h:156: ‘strcpy’ is already declared in this scope
/usr/include/string.h:156: ‘strlen’ is already declared in this scope

It would appear that there was a bug in the specs file.

Edit /usr/lib/gcc-lib/ntox86/2.95.2/specs

find

*cc1plus:
-fhonor-std

and change it to

*cc1plus:
%(cc1plus_spec) -fhonor-std -fno-builtin

but it seems like a larger problem is with ‘cc’

e.g. ‘cc f.c’ gives me ‘invalid pre-processing directive name’
and '/usr/lib/gcc-lib/ntox86/2.95.2/cpp error 33
:1: invalid #-line

(my top line of f.c is #include <stdlib.h>)

Is this par for the course, or has my installation botched somewhere?

It doesn’t do that for me. Take a look at the preprocessed output (ie
cc -P f.c, then look at f.i)


cburgess@qnx.com

Thanks Colin

It is a little better now - still some problems.

The ‘invalid preprocessing directive’ was a typo in the quick hello-world
code I typed up when things were already bad, so I didn’t check it as
thoroughly as I should have (it actually said #!include <stdlib.h>).

Still, I’m having trouble further down the compile (this same code definitely
works on both QNX 4.25 and Linux)

/usr/include/string.h: In function void * std::memchr(void *, int, unsigned int)': /usr/include/string.h:125: declaration of C function void * std::memchr(void
*, int, unsigned int)’ conflicts with
/usr/include/string.h:49: previous declaration `const void *
std::memchr(const void *, int, unsigned int)’ here

and so on for strchr, strpbrk, strstr, (though they say ‘passing …’,
‘discards qualifiers’)

cheers
Lance

Colin Burgess wrote:

Hi Lance,

Lance Roberts <> lance@econz.co.nz> > wrote:
Hi Guys,

I have a weird problem using g++ - only since upgrading to 6.1
Initially I had lost ‘cvs’, so I did a full install of all new stuff on
the CD (e.g X server, PhAster, etc - I did a ‘full’ install to get
upgraded, but it seemed to have left a lot of it out).

Now, I get messages such as :

In file included from test.cpp:32:
/usr/include/string.h:155: ‘memcmp’ is already declared in this scope
/usr/include/string.h:155: ‘memcpy’ is already declared in this scope
/usr/include/string.h:156: ‘strcmp’ is already declared in this scope
/usr/include/string.h:156: ‘strcpy’ is already declared in this scope
/usr/include/string.h:156: ‘strlen’ is already declared in this scope

It would appear that there was a bug in the specs file.

Edit /usr/lib/gcc-lib/ntox86/2.95.2/specs

find

*cc1plus:
-fhonor-std

and change it to

*cc1plus:
%(cc1plus_spec) -fhonor-std -fno-builtin

but it seems like a larger problem is with ‘cc’

e.g. ‘cc f.c’ gives me ‘invalid pre-processing directive name’
and '/usr/lib/gcc-lib/ntox86/2.95.2/cpp error 33
:1: invalid #-line

(my top line of f.c is #include <stdlib.h>)

Is this par for the course, or has my installation botched somewhere?

It doesn’t do that for me. Take a look at the preprocessed output (ie
cc -P f.c, then look at f.i)


cburgess@qnx.com

Lance Roberts <lance@econz.co.nz> wrote:

Hi Guys,

I have a weird problem using g++ - only since upgrading to 6.1
Initially I had lost ‘cvs’, so I did a full install of all new stuff on
the CD (e.g X server, PhAster, etc - I did a ‘full’ install to get
upgraded, but it seemed to have left a lot of it out).

The 6.1 release also has the move from the g++ C++ library to the Dinkum
library and headers. Try doing this…

#include
#include

chris

cdm@qnx.com > “The faster I go, the behinder I get.”

Chris McKillop – Lewis Carroll –
Software Engineer, QSSL
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

Chris McKillop <cdm@qnx.com> wrote:

Lance Roberts <> lance@econz.co.nz> > wrote:

Hi Guys,

I have a weird problem using g++ - only since upgrading to 6.1
Initially I had lost ‘cvs’, so I did a full install of all new stuff on
the CD (e.g X server, PhAster, etc - I did a ‘full’ install to get
upgraded, but it seemed to have left a lot of it out).


The 6.1 release also has the move from the g++ C++ library to the Dinkum
library and headers. Try doing this…

#include <cstdio
#include <cstring

I do not have the ISO C++ std at hand but
there is nothing wrong in doing #include <stdio.h>
in a C++ program(except a question of style)
IIRC,

#include <stdio.h>

is equivalent to

#include
using namespace std;

\

alain

Alain Magloire <alain@reliant.qnx.com> wrote:

I do not have the ISO C++ std at hand but
there is nothing wrong in doing #include <stdio.h
in a C++ program(except a question of style)
IIRC,

#include <stdio.h

is equivalent to

#include <cstdio
using namespace std;

Is that required by the standard or just something that most vendors are
doing to keep the complaints down? :slight_smile: I only sugested it since I have
talked with others moving their C++ project to 6.1 from 6.0 and this was
the only way we could get everything to compile cleanly. I have not
tinkered enough to comment any further then this.

chris

cdm@qnx.com > “The faster I go, the behinder I get.”

Chris McKillop – Lewis Carroll –
Software Engineer, QSSL
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

I do not have the ISO C++ std at hand but
there is nothing wrong in doing #include <stdio.h
in a C++ program(except a question of style)
IIRC,

#include <stdio.h

is equivalent to

#include <cstdio
using namespace std;


Is that required by the standard or just something that most vendors are
doing to keep the complaints down? > :slight_smile: > I only sugested it since I have
talked with others moving their C++ project to 6.1 from 6.0 and this was
the only way we could get everything to compile cleanly. I have not
tinkered enough to comment any further then this.

So basically, you are asking 1 million users
and breaking 80% of existing C++ code, just because of that !

This is the content of <cstring.h> on MSVC 5 as an example:

// cstring standard header
#ifndef CSTRING
#define CSTRING
#ifdef _STD_USING
#undef _STD_USING
#include <string.h>
#define _STD_USING
#else
#include <string.h>
#endif /* _STD_USING /
#endif /
CSTRING */

/*

  • Copyright (c) 1994 by P.J. Plauger. ALL RIGHTS RESERVED.
  • Consult your license regarding permissions and restrictions.
    */

===============================================================

If you are “forcing” folks to upgrade their existing lines of code,
this is really a BAD thing to do.

In other words, I won’t upgrade.

Sincerly,
Fred.

In article <9j8sti$c64$1@nntp.qnx.com>, Chris McKillop <cdm@qnx.com>
wrote:

Alain Magloire <> alain@reliant.qnx.com> > wrote:
#include <stdio.h

is equivalent to

#include <cstdio
using namespace std;


Is that required by the standard or just something that most vendors are
doing to keep the complaints down? > :slight_smile:

There is a requirement vis a vis namespace std and stdio.h, but it is
not exactly what Alain describes.

is required, by ANSI, to declare a set of symbols with which we
are familar as the stdio functions (I won’t belabor which functions
those are – I suspect we all know). ANSI further requires that those
symbols declare by cstdio are declare in namespace std. Thus, printf is
really std::printf.

<stdio.h> is required to declare that same set of symbols, but to
declare them in the global namespace, thus printf is ::printf.

Many vendors do this by writing cstdio as Alain wrote above. Such an
implementation is subtly wrong because it forces all of namespace std to
be referencable in the global namespace. Thus, the following program
would compile in such an implementation, but should not under strict
interpretation of the ANSI documents:

#include
#include <stdio.h>

int
main()
{
::printf(“Hello world\n”); // Ok
::strcmp(“Hello”, “World”); // Technically, not compliant
}

This is a subtle hair and probably not important to the conversation at
hand. The salient point, I believe, is that #include’ing <stdio.h> is
required to make functions like printf and other “stdio functions”
accessible without the std:: prefix and without otherwise including the
global “using namespace std” clause in all one’s source files.

Hope this helps,
Eric

IF you look in /usr/include/string.h there is a small issue with
the symbol declarations. If you are using g++ you might want to
change…

#ifndef __GCC_BUILTIN
using std::memcmp; using std::memcpy;
using std::strcmp; using std::strcpy; using std::strlen;
#endif

to

#if 0
#ifndef __GCC_BUILTIN
using std::memcmp; using std::memcpy;
using std::strcmp; using std::strcpy; using std::strlen;
#endif
#endif

The other work-around is to use qcc instead of g++ to do the build and link.

chris


Lance Roberts <lance@econz.co.nz> wrote:

Hi Guys,

I have a weird problem using g++ - only since upgrading to 6.1
Initially I had lost ‘cvs’, so I did a full install of all new stuff on
the CD (e.g X server, PhAster, etc - I did a ‘full’ install to get
upgraded, but it seemed to have left a lot of it out).

Now, I get messages such as :

In file included from test.cpp:32:
/usr/include/string.h:155: ‘memcmp’ is already declared in this scope
/usr/include/string.h:155: ‘memcpy’ is already declared in this scope
/usr/include/string.h:156: ‘strcmp’ is already declared in this scope
/usr/include/string.h:156: ‘strcpy’ is already declared in this scope
/usr/include/string.h:156: ‘strlen’ is already declared in this scope

but it seems like a larger problem is with ‘cc’

e.g. ‘cc f.c’ gives me ‘invalid pre-processing directive name’
and '/usr/lib/gcc-lib/ntox86/2.95.2/cpp error 33
:1: invalid #-line

(my top line of f.c is #include <stdlib.h>)

Is this par for the course, or has my installation botched somewhere?

cheers
Lance

cdm@qnx.com > “The faster I go, the behinder I get.”

Chris McKillop – Lewis Carroll –
Software Engineer, QSSL
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<