string.h

it’s me again, colin :slight_smile:
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

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. :frowning:

Kris

<fliu@bb.vipstage.com> wrote in message news:a9hopj$avk$1@inn.qnx.com

it’s me again, colin > :slight_smile:
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

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. > :frowning:

Kris

fliu@bb.vipstage.com> > wrote in message news:a9hopj$avk$> 1@inn.qnx.com> …
it’s me again, colin > :slight_smile:
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

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 > :slight_smile:
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

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
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 > :slight_smile:
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

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/

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

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

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

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+shm&hl=en&selm=9crts9%24s35%241%40nntp.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. > :frowning:

Kris

fliu@bb.vipstage.com> > wrote in message news:a9hopj$avk$> 1@inn.qnx.com> …
it’s me again, colin > :slight_smile:
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 <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

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. :wink:

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+shm&hl=en&selm=9crts9%24s35%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. > :frowning:

Kris

fliu@bb.vipstage.com> > wrote in message news:a9hopj$avk$> 1@inn.qnx.com> …
it’s me again, colin > :slight_smile:
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

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

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

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 , that is hidden
in /usr/lib/gcc-lib/…/… directory?
Dinkum seems to have in /usr/include/cpp, but GNU c++ doesn’t
have it in /usr/include/g+±3. isn’t the in /usr/lib/gcc-lib/…
for GNU c++??

Thanks!
frank

Colin Burgess <cburgess@qnx.com> wrote:

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)

I just had another fresh new install of 6.2beta (BMW) and it
still only has the static libstdc++ after I installed the DEV
package. Maybe you can follow up on that? Hopefully this will
be fixed in the 6.2 release.

btw, I found an interesting thing today: the mozilla-gtk
binary I built a while ago on 6.1 always sigsegv at the
same place. today I copy the binary to the new 6.2beta box
and it works! It must be some bugs in the 6.1 (libcpp.so ??)
that is fixed in 6.2. Any thoughts?

thanks,

Frank

fliu@bb.vipstage.com wrote:

btw, I found an interesting thing today: the mozilla-gtk
binary I built a while ago on 6.1 always sigsegv at the
same place. today I copy the binary to the new 6.2beta box
and it works! It must be some bugs in the 6.1 (libcpp.so ??)
that is fixed in 6.2. Any thoughts?

i just tracked down the problem. it is in libc.so.2
(see my posting in the bmw beta private group).

frank

fliu@bb.vipstage.com wrote:

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

Bug in the specs file. There is a -nostdinc there which shouldn’t be.
It was put there for the old Dinkum C++ layout since it was accidentally
getting a mix of G++ and Dinkum headers if you didn’t. With the new layout
that isn’t a problem, and since g++ now is supposed to use the G++ stuff,
then it’s ok to remove the -nostdinc.

\

cburgess@qnx.com

Colin Burgess <cburgess@qnx.com> wrote:

fliu@bb.vipstage.com > wrote:
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

Bug in the specs file. There is a -nostdinc there which shouldn’t be.
It was put there for the old Dinkum C++ layout since it was accidentally
getting a mix of G++ and Dinkum headers if you didn’t. With the new layout
that isn’t a problem, and since g++ now is supposed to use the G++ stuff,
then it’s ok to remove the -nostdinc.

thanks for the clarification.
there are also some references to nostdlib in the specs file in 6.2.
are those also the leftovers from old Dinkum c++ layout?

frank

there are also some references to nostdlib in the specs file in 6.2.
are those also the leftovers from old Dinkum c++ layout?

Yes, I’ve asked someone to look into that.


cburgess@qnx.com