qnx6.1 & string.h
Lance Roberts
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
Alain Magloire
Submit a PR to qnx.com about this. In the first case it looks
like the gcc driver is broken(probably the spec file). Meanwhile
you could try 'qcc', it should work. Probably compiling with
option '-fno-builtin' when using the gcc driver could get you pass
the first error.
> cheers
> Lance
Colin Burgess
Lance Roberts <la...@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)
Mritunjai
I too was initially hurt byt this... but this turned out to be a problem with
ourselves. 6.1 libraries are ISO C++ compliant, so you need to
#include <cstring>
and *not* string.h, ditto for other libs. Also you'll need "using namespace
std;" directive. And i recommed using "-fno-builtins" option while compiling to
avoid conflict while compiling between in built and standard functions (you can
also use std::function(...) to explicitely state that you need standard version)
Previously Lance Roberts said-
--
Keep Smiling
Regards
- mritunjai
Lance Roberts
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
Chris McKillop
>
> 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>
...
chris
--
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
c...@qnx.com "The faster I go, the behinder I get."
Chris McKillop -- Lewis Carroll --
Software Engineer, QSSL
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Alain Magloire
> Lance Roberts <la...@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 <cstdio>
using namespace std;
--
alain
Chris McKillop
>
> 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? :) 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.
Alain Magloire
> Alain Magloire <al...@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? :)
Again I do not have the ISO C++ at hand for a definitive answer, but
yes I believe it is part of the std. IIRC in ISO C++, C headers like
<xx.h> will have a corresponding <cxx>. The former makes xx.h functions
available in the global namespace.
I expect the code below to compile with a C++ compiler:
#include <stdio.h>
int main ()
{
printf ("Hello world\n");
return 0;
}
with no need change <stdio.h> --> <cstdio>, same goes for <string.h>
--
alain
Mritunjai
Previously Alain wrote-
>Again I do not have the ISO C++ at hand for a definitive answer, but
>yes I believe it is part of the std. IIRC in ISO C++, C headers like
><xx.h> will have a corresponding <cxx>. The former makes xx.h functions
>available in the global namespace.
>
>I expect the code below to compile with a C++ compiler:
>
>#include <stdio.h>
>int main ()
>{
> printf ("Hello world\n");
> return 0;
>}
>
>with no need change <stdio.h> --> <cstdio>, same goes for <string.h>
>
>--
>alain
Yes it will, provided you tell compiler to honor std namespace, and disable
builtin functions (if you use any! like strlen)
g++ my.cc -fno-builtin -fhonor-std
The std namespace is not implicitely allowed in global namespace.
Fred
>> 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? :) 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.
Eric Berdahl
wrote:
> Alain Magloire <al...@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? :)
There is a requirement vis a vis namespace std and stdio.h, but it is
not exactly what Alain describes.
<cstdio> 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 <cstring>
#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
Chris McKillop
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
--