string.h

bridged with qdn.public.qnxrtp.devtools
Guest

string.h

Post by Guest » Tue Apr 16, 2002 5:59 pm

it's me again, colin :)
hope you are doing well.
any quick fixes for the following?

g++ sees conflicting defines/declarations in string.h
(memchr,strchr,strpbrk,strrchr, strstr)

eg:
extern _Const_return char *strchr( const char *__s, int __c );
...
inline char *strchr(char *_S, int _C)
{ /* call with const first argument */
union { char *_Out; _Const_return char * _In; } _Result;
return (_Result._In = _CSTD strchr((const char *)_S, _C)), _Result._Out;...
using std::strcat; using std::strchr; using std::strncat;
....

frank

Kris Warkentin

Re: string.h

Post by Kris Warkentin » Tue Apr 16, 2002 8:15 pm

There was some talk about this on the gcc mailing list. It seems like we
aren't the only ones suffering from this problem. Apparently the ANSI/ISO
C++ specification whatchamacallit states that certain functions
(particularily string type functions) need to be defined in both the std and
global namespaces. As you might imagine, this can make life very difficult
for compilers. It wasn't altogether clear what was going to be done about
it - I recall some talk of using some __builtin_* functions or some such but
I didn't see any more about the issue. It looks like our header files are
technically correct but the specification is causing compiler problems.
Sorry I don't have any more information or a fix. :-(

Kris

<fliu@bb.vipstage.com> wrote in message news:a9hopj$avk$1@inn.qnx.com...
it's me again, colin :)
hope you are doing well.
any quick fixes for the following?

g++ sees conflicting defines/declarations in string.h
(memchr,strchr,strpbrk,strrchr, strstr)

eg:
extern _Const_return char *strchr( const char *__s, int __c );
..
inline char *strchr(char *_S, int _C)
{ /* call with const first argument */
union { char *_Out; _Const_return char * _In; } _Result;
return (_Result._In = _CSTD strchr((const char *)_S, _C)),
_Result._Out;...
using std::strcat; using std::strchr; using std::strncat;
...

frank

Guest

Re: string.h

Post by Guest » Tue Apr 16, 2002 8:40 pm

How come I don't see the error in Linux?
Maybe they are using some kludge? Can't we do something in qnx also?
Thanks!
Frank

Kris Warkentin <kewarken@qnx.com> wrote:
There was some talk about this on the gcc mailing list. It seems like we
aren't the only ones suffering from this problem. Apparently the ANSI/ISO
C++ specification whatchamacallit states that certain functions
(particularily string type functions) need to be defined in both the std and
global namespaces. As you might imagine, this can make life very difficult
for compilers. It wasn't altogether clear what was going to be done about
it - I recall some talk of using some __builtin_* functions or some such but
I didn't see any more about the issue. It looks like our header files are
technically correct but the specification is causing compiler problems.
Sorry I don't have any more information or a fix. :-(

Kris

fliu@bb.vipstage.com> wrote in message news:a9hopj$avk$1@inn.qnx.com...
it's me again, colin :)
hope you are doing well.
any quick fixes for the following?

g++ sees conflicting defines/declarations in string.h
(memchr,strchr,strpbrk,strrchr, strstr)

eg:
extern _Const_return char *strchr( const char *__s, int __c );
..
inline char *strchr(char *_S, int _C)
{ /* call with const first argument */
union { char *_Out; _Const_return char * _In; } _Result;
return (_Result._In = _CSTD strchr((const char *)_S, _C)),
_Result._Out;...
using std::strcat; using std::strchr; using std::strncat;
...

frank

Colin Burgess

Re: string.h

Post by Colin Burgess » Tue Apr 16, 2002 9:25 pm

There's a bug in our compiler configuration that adds an
explicit extern "C" around system header files.

Make sure that g++ doesn't include /usr/include with a
-isystem, rather have it use -idirafter

fliu@bb.vipstage.com wrote:
it's me again, colin :)
hope you are doing well.
any quick fixes for the following?

g++ sees conflicting defines/declarations in string.h
(memchr,strchr,strpbrk,strrchr, strstr)

eg:
extern _Const_return char *strchr( const char *__s, int __c );
..
inline char *strchr(char *_S, int _C)
{ /* call with const first argument */
union { char *_Out; _Const_return char * _In; } _Result;
return (_Result._In = _CSTD strchr((const char *)_S, _C)), _Result._Out;...
using std::strcat; using std::strchr; using std::strncat;
...

frank
--
cburgess@qnx.com

Guest

Re: string.h

Post by Guest » Tue Apr 16, 2002 9:39 pm

Colin Burgess <cburgess@qnx.com> wrote:
There's a bug in our compiler configuration that adds an
explicit extern "C" around system header files.
is it fixed in 6.2beta? I am going to try it later.
btw, in 6.2beta, there is a /usr/include/cpp directory with
files such as new.h
in new.h, you have
#include <new>
since new is under /usr/include/cpp, shouldn't it be
#include <cpp/new>
??
same problem for other files in /usr/include/cpp directory with #include.

what is the purpose for this separate /usr/include/cpp ?
because of Dinknum, libstdc++ ?
how shall we pick one of them?
QCC -V dinknum ..
QCC -V gnu .. ???

thanks!
frank
Make sure that g++ doesn't include /usr/include with a
-isystem, rather have it use -idirafter

fliu@bb.vipstage.com wrote:
it's me again, colin :)
hope you are doing well.
any quick fixes for the following?

g++ sees conflicting defines/declarations in string.h
(memchr,strchr,strpbrk,strrchr, strstr)

eg:
extern _Const_return char *strchr( const char *__s, int __c );
..
inline char *strchr(char *_S, int _C)
{ /* call with const first argument */
union { char *_Out; _Const_return char * _In; } _Result;
return (_Result._In = _CSTD strchr((const char *)_S, _C)), _Result._Out;...
using std::strcat; using std::strchr; using std::strncat;
...

frank

Chris McKillop

Re: string.h

Post by Chris McKillop » Tue Apr 16, 2002 10:22 pm

fliu@bb.vipstage.com wrote:
How come I don't see the error in Linux?
Maybe they are using some kludge? Can't we do something in qnx also?
Nah, they are just simply not using "standard" C++ headers but rather just
the headers from g++ (AFAIK). It is the headers from the Dinkum C++ library
that is causing the pain. Again, AFAIK.

chris


--
Chris McKillop <cdm@qnx.com> "The faster I go, the behinder I get."
Software Engineer, QSSL -- Lewis Carroll --
http://qnx.wox.org/

Colin Burgess

Re: string.h

Post by Colin Burgess » Wed Apr 17, 2002 3:39 am

fliu@bb.vipstage.com wrote:
Colin Burgess <cburgess@qnx.com> wrote:
There's a bug in our compiler configuration that adds an
explicit extern "C" around system header files.

is it fixed in 6.2beta? I am going to try it later.
Argh, it isn't. It's fixed in the head branch, but fell into CVS
and GNATS limbo and didn't go anywhere from there. I'll follow up...

However, the specs files do use idirafter at least.

/usr/include/cpp is Dinkum C++ (-Vgcc_ntox86_cpp)
/usr/include/ecpp is Embedded Dinkum C++ (-Vgcc_ntox86_ecpp)
/usr/include/g++-3 is GNU C++ (-Vgcc_ntox86_gpp)

--
cburgess@qnx.com

Guest

Re: string.h

Post by Guest » Wed Apr 17, 2002 4:06 am

Colin Burgess <cburgess@qnx.com> wrote:
/usr/include/cpp is Dinkum C++ (-Vgcc_ntox86_cpp)
/usr/include/ecpp is Embedded Dinkum C++ (-Vgcc_ntox86_ecpp)
/usr/include/g++-3 is GNU C++ (-Vgcc_ntox86_gpp)
shouldn't the files in those subdirectories reference each other
with <cpp/xxx>, <ecpp/xxx> and <g++-3/xxx>
eg: for file /usr/include/cpp/new and /usr/include/cpp/new.h
"new" has a "#include <new.h>". shouldn't it be "#include <cpp/new.h>"?

looks like this has been our conventional in 6.0, 6.1,
eg: /usr/include/sys/dir.h, /usr/include/sys/platform.h
dir.h has "#include <sys/platform.h>", NOT "#include <platform.h>

why don't we follow this convention in 6.2 for cpp, ecpp, g++-3 ?

Frank

Guest

Re: string.h

Post by Guest » Wed Apr 17, 2002 4:18 am

Colin Burgess <cburgess@qnx.com> wrote:
/usr/include/cpp is Dinkum C++ (-Vgcc_ntox86_cpp)
/usr/include/ecpp is Embedded Dinkum C++ (-Vgcc_ntox86_ecpp)
/usr/include/g++-3 is GNU C++ (-Vgcc_ntox86_gpp)
if i do "g++" by itself, what is the default? Dinkum?
how to change the default? modifying the spec file?

btw, how come there is no shared version of libstdc++ in /lib ?
this will cause a problem for mozillia, because qnx can't deal
with shared and static together (as we discussed in another thread).

frank

Guest

Re: string.h

Post by Guest » Wed Apr 17, 2002 2:01 pm

Hi Kris,
Glad to see you here.
At one time, you wrote some wrapper for shm stuff. I am wondering if
6.2 will officially have support for it?

cdm, it's been a year since this post, maybe your sysv manager is
about ready?
http://groups.google.com/groups?q=kris+ ... com&rnum=1

Frank

Kris Warkentin <kewarken@qnx.com> wrote:
There was some talk about this on the gcc mailing list. It seems like we
aren't the only ones suffering from this problem. Apparently the ANSI/ISO
C++ specification whatchamacallit states that certain functions
(particularily string type functions) need to be defined in both the std and
global namespaces. As you might imagine, this can make life very difficult
for compilers. It wasn't altogether clear what was going to be done about
it - I recall some talk of using some __builtin_* functions or some such but
I didn't see any more about the issue. It looks like our header files are
technically correct but the specification is causing compiler problems.
Sorry I don't have any more information or a fix. :-(

Kris

fliu@bb.vipstage.com> wrote in message news:a9hopj$avk$1@inn.qnx.com...
it's me again, colin :)
hope you are doing well.
any quick fixes for the following?

g++ sees conflicting defines/declarations in string.h
(memchr,strchr,strpbrk,strrchr, strstr)

eg:
extern _Const_return char *strchr( const char *__s, int __c );
..
inline char *strchr(char *_S, int _C)
{ /* call with const first argument */
union { char *_Out; _Const_return char * _In; } _Result;
return (_Result._In = _CSTD strchr((const char *)_S, _C)),
_Result._Out;...
using std::strcat; using std::strchr; using std::strncat;
...

frank

Guest

Re: string.h

Post by Guest » Wed Apr 17, 2002 4:56 pm

Colin Burgess <cburgess@qnx.com> wrote:
fliu@bb.vipstage.com wrote:
Colin Burgess <cburgess@qnx.com> wrote:
There's a bug in our compiler configuration that adds an
explicit extern "C" around system header files.

is it fixed in 6.2beta? I am going to try it later.

Argh, it isn't. It's fixed in the head branch, but fell into CVS
and GNATS limbo and didn't go anywhere from there. I'll follow up...

However, the specs files do use idirafter at least.
I did a diff between the "specs" file from 6.1 and 6.2,
don't see any differences, except the gcc version number
and the famous "-fhonor-std -fno-builtin " line.

"idirafter" is in both specs files.

frank

Kris Warkentin

Re: string.h

Post by Kris Warkentin » Wed Apr 17, 2002 7:00 pm

I don't know either. I know there was talk about supporting the system V
stuff but I never heard any more. I'm just glad we've finally got Unix
domain sockets. ;-)

Kris

<fliu@bb.vipstage.com> wrote in message news:a9jv85$144$1@inn.qnx.com...
Hi Kris,
Glad to see you here.
At one time, you wrote some wrapper for shm stuff. I am wondering if
6.2 will officially have support for it?

cdm, it's been a year since this post, maybe your sysv manager is
about ready?

http://groups.google.com/groups?q=kris+ ... %241%40nnt
p.qnx.com&rnum=1
Frank

Kris Warkentin <kewarken@qnx.com> wrote:
There was some talk about this on the gcc mailing list. It seems like
we
aren't the only ones suffering from this problem. Apparently the
ANSI/ISO
C++ specification whatchamacallit states that certain functions
(particularily string type functions) need to be defined in both the std
and
global namespaces. As you might imagine, this can make life very
difficult
for compilers. It wasn't altogether clear what was going to be done
about
it - I recall some talk of using some __builtin_* functions or some such
but
I didn't see any more about the issue. It looks like our header files
are
technically correct but the specification is causing compiler problems.
Sorry I don't have any more information or a fix. :-(

Kris

fliu@bb.vipstage.com> wrote in message news:a9hopj$avk$1@inn.qnx.com...
it's me again, colin :)
hope you are doing well.
any quick fixes for the following?

g++ sees conflicting defines/declarations in string.h
(memchr,strchr,strpbrk,strrchr, strstr)

eg:
extern _Const_return char *strchr( const char *__s, int __c );
..
inline char *strchr(char *_S, int _C)
{ /* call with const first argument */
union { char *_Out; _Const_return char * _In; } _Result;
return (_Result._In = _CSTD strchr((const char *)_S, _C)),
_Result._Out;...
using std::strcat; using std::strchr; using std::strncat;
...

frank

Colin Burgess

Re: string.h

Post by Colin Burgess » Wed Apr 17, 2002 9:39 pm

The directory paths are added to the include search, so you don't need
to mention the subdir. This is how you select between the differing
C++ versions.

fliu@bb.vipstage.com wrote:
Colin Burgess <cburgess@qnx.com> wrote:

/usr/include/cpp is Dinkum C++ (-Vgcc_ntox86_cpp)
/usr/include/ecpp is Embedded Dinkum C++ (-Vgcc_ntox86_ecpp)
/usr/include/g++-3 is GNU C++ (-Vgcc_ntox86_gpp)

shouldn't the files in those subdirectories reference each other
with <cpp/xxx>, <ecpp/xxx> and <g++-3/xxx
eg: for file /usr/include/cpp/new and /usr/include/cpp/new.h
"new" has a "#include <new.h>". shouldn't it be "#include <cpp/new.h>"?

looks like this has been our conventional in 6.0, 6.1,
eg: /usr/include/sys/dir.h, /usr/include/sys/platform.h
dir.h has "#include <sys/platform.h>", NOT "#include <platform.h

why don't we follow this convention in 6.2 for cpp, ecpp, g++-3 ?

Frank
--
cburgess@qnx.com

Colin Burgess

Re: string.h

Post by Colin Burgess » Wed Apr 17, 2002 9:41 pm

fliu@bb.vipstage.com wrote:
Colin Burgess <cburgess@qnx.com> wrote:

/usr/include/cpp is Dinkum C++ (-Vgcc_ntox86_cpp)
/usr/include/ecpp is Embedded Dinkum C++ (-Vgcc_ntox86_ecpp)
/usr/include/g++-3 is GNU C++ (-Vgcc_ntox86_gpp)

if i do "g++" by itself, what is the default? Dinkum?
how to change the default? modifying the spec file?
g++ defaults to the GNU C++ stuff. If you want to use dinkum with
g++, then you'll have to add

-nostdinc++ -I /usr/include/cpp
and
-nostdlib++ -lcpp -lm

to your link lines, or use qcc -Vgcc_ntox86_cpp
btw, how come there is no shared version of libstdc++ in /lib ?
this will cause a problem for mozillia, because qnx can't deal
with shared and static together (as we discussed in another thread).
Must be a packaging error - I have one (6.2 beta)

--
cburgess@qnx.com

Guest

Re: string.h

Post by Guest » Wed Apr 17, 2002 10:42 pm

Colin Burgess <cburgess@qnx.com> wrote:
g++ defaults to the GNU C++ stuff. If you want to use dinkum with
g++, then you'll have to add
I assume "c++" is equivalent to "g++", which defaults to GNU C++?

btw, how come "c++" can't find the header <new>, that is hidden
in /usr/lib/gcc-lib/.../... directory?
Dinkum seems to have <new> in /usr/include/cpp, but GNU c++ doesn't
have it in /usr/include/g++-3. isn't the <new> in /usr/lib/gcc-lib/..
for GNU c++??

Thanks!
frank

Post Reply

Return to “qdn.public.qnxrtp.devtools”