subject:"libc functions from c\+\+ issues"

Re: libc functions from c++ issues

2022-04-13 Thread Chris Johns

On 14/4/2022 1:51 pm, Joel Sherrill wrote:
> On Wed, Apr 13, 2022, 9:14 PM Chris Johns  > wrote:
> 
> On 14/4/2022 6:58 am, Joel Sherrill wrote:
> > When you use -std= with gcc, it says to strictly enforce that standard. 
> C++ is
> > NOT POSIX so pthread.h prototypes aren't visible.  There are some edge 
> cases
> > where gcc isn't that strict until -pedantic is turned on. Use of long 
> long in
> > C++03 is an example of that. 
> >
> > -D_POSIX_C_SOURCE=200809 is precisely the answer I think but 
> -D_GNU_SOURCE
> > enables almost everything I think.
> >
> > Anyway, here's a small Makefile with some comments to help:
> 
> Nice and thanks. I reviewed the flags on this page:
> 
> 
> https://www.gnu.org/software/libc/manual/html_node/Feature-Test-Macros.html
> 
> 
> 
> And adding `_XOPEN_SOURCE` to the compiler command line allowed the code 
> to
> build. I will raise the strict vs non-strict issue with the project. I 
> suspect
> they are not aware there is an issue.
> 
> One thing I've learned from working the FACE Technical Standard is that it is
> common to think you are closely following a standard but the tools and
> environment don't enforce it like you think. 
> 
> When you get the warnings down (assume there are some/lots), turn on -Wall and
> -pedantic and see where else the code isn't strictly following things.

 I shudder at the thought.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: libc functions from c++ issues

2022-04-13 Thread Joel Sherrill

On Wed, Apr 13, 2022, 9:14 PM Chris Johns  wrote:

> On 14/4/2022 6:58 am, Joel Sherrill wrote:
> > When you use -std= with gcc, it says to strictly enforce that standard.
> C++ is
> > NOT POSIX so pthread.h prototypes aren't visible.  There are some edge
> cases
> > where gcc isn't that strict until -pedantic is turned on. Use of long
> long in
> > C++03 is an example of that.
> >
> > -D_POSIX_C_SOURCE=200809 is precisely the answer I think but
> -D_GNU_SOURCE
> > enables almost everything I think.
> >
> > Anyway, here's a small Makefile with some comments to help:
>
> Nice and thanks. I reviewed the flags on this page:
>
> https://www.gnu.org/software/libc/manual/html_node/Feature-Test-Macros.html
>
> And adding `_XOPEN_SOURCE` to the compiler command line allowed the code to
> build. I will raise the strict vs non-strict issue with the project. I
> suspect
> they are not aware there is an issue.
>

One thing I've learned from working the FACE Technical Standard is that it
is common to think you are closely following a standard but the tools and
environment don't enforce it like you think.

When you get the warnings down (assume there are some/lots), turn on -Wall
and -pedantic and see where else the code isn't strictly following things.




> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: libc functions from c++ issues

2022-04-13 Thread Chris Johns

On 14/4/2022 6:58 am, Joel Sherrill wrote:
> When you use -std= with gcc, it says to strictly enforce that standard. C++ is
> NOT POSIX so pthread.h prototypes aren't visible.  There are some edge cases
> where gcc isn't that strict until -pedantic is turned on. Use of long long in
> C++03 is an example of that. 
> 
> -D_POSIX_C_SOURCE=200809 is precisely the answer I think but -D_GNU_SOURCE
> enables almost everything I think.
> 
> Anyway, here's a small Makefile with some comments to help:

Nice and thanks. I reviewed the flags on this page:

https://www.gnu.org/software/libc/manual/html_node/Feature-Test-Macros.html

And adding `_XOPEN_SOURCE` to the compiler command line allowed the code to
build. I will raise the strict vs non-strict issue with the project. I suspect
they are not aware there is an issue.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: libc functions from c++ issues

2022-04-13 Thread Joel Sherrill

When you use -std= with gcc, it says to strictly enforce that standard. C++
is NOT POSIX so pthread.h prototypes aren't visible.  There are some edge
cases where gcc isn't that strict until -pedantic is turned on. Use of long
long in C++03 is an example of that.

-D_POSIX_C_SOURCE=200809 is precisely the answer I think but -D_GNU_SOURCE
enables almost everything I think.

Anyway, here's a small Makefile with some comments to help:

===

CXX=sparc-rtems6-g++
CXXFLAGS=-pthread -O2 -g

# When you turn on a -std=c++, it disables everything not strictly in
# the standard
CXXFLAGS += -std=c++11
# And you need to turn it back on -- either of these will work
#CXXFLAGS += -D_POSIX_C_SOURCE=200809
CXXFLAGS += -D_GNU_SOURCE

all: t.o

t.o: t.cc Makefile

clean:
rm -rf t *.o
===

On Tue, Apr 12, 2022 at 3:24 AM Karel Gardas 
wrote:

> On 4/12/22 10:05, Chris Johns wrote:
> > I think there is something else happening here. If I use a 4.11 compiler
> the
> > `setenv` call is not seen but `pthread_kill` is. Maybe 6 is more
> standards
> > compliant? I do not know.
> >
> > I am porting a large piece of existing code to RTEMS and that code
> compiles and
> > runs on current Linux systems.
> >
> > Why does Linux build this code and we do not?
> >
> > Should we be compatible or standards compliant?
>
> This is million dollar question.
>
> But I can offer just simple advice: try to compile the code in question
> on Solaris (11 or even better 10). In the past it was much more strict
> about standard than both Linux and BSD camp hence I usually used that
> for detecting: is the code Linux specific or is it written to be more
> portable and standards compliant? It'll just give you a sign although in
> this particular case of C/C++ integration it may not work that well...
>
> Good luck!
> Karel
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: libc functions from c++ issues

2022-04-12 Thread Karel Gardas


On 4/12/22 10:05, Chris Johns wrote:

I think there is something else happening here. If I use a 4.11 compiler the
`setenv` call is not seen but `pthread_kill` is. Maybe 6 is more standards
compliant? I do not know.

I am porting a large piece of existing code to RTEMS and that code compiles and
runs on current Linux systems.

Why does Linux build this code and we do not?

Should we be compatible or standards compliant?


This is million dollar question.

But I can offer just simple advice: try to compile the code in question 
on Solaris (11 or even better 10). In the past it was much more strict 
about standard than both Linux and BSD camp hence I usually used that 
for detecting: is the code Linux specific or is it written to be more 
portable and standards compliant? It'll just give you a sign although in 
this particular case of C/C++ integration it may not work that well...


Good luck!
Karel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: libc functions from c++ issues

2022-04-12 Thread Chris Johns

On 12/4/2022 5:18 pm, Karel Gardas wrote:
> 
> Not sure, but isn't usage of C headers in C++ deprecated for a long time now?
> Shouldn't you use csignal and cstdlib? 

These functions are not defined in a C++ namespace so you are required to use C
functions to use them. I am not what the rational is but I am sure there is one.

> Newlib provided for RTEMS looks to push
> that even a bit further by providing C++ specific stdlib.h (in include/c++ and
> in include/c++/tr1) which just includes cstdlib and exports symbols out from 
> std
> name space and this way basically hides C specific stdlib.h
> 
> I'd bet newlib is more correct here, but I'm no expert...
> 
> Anyway in the c++/newlib case and if you really insist on c++ compiler here,

The issue is not what I want. I would simply manage this issue some other way,
ie a C call that wraps the functions I wish to use. :)

> have you tried to use include_next trick by defining
> _GLIBCXX_INCLUDE_NEXT_C_HEADERS? See include/c++/stdlib.h from tools...

I think there is something else happening here. If I use a 4.11 compiler the
`setenv` call is not seen but `pthread_kill` is. Maybe 6 is more standards
compliant? I do not know.

I am porting a large piece of existing code to RTEMS and that code compiles and
runs on current Linux systems.

Why does Linux build this code and we do not?

Should we be compatible or standards compliant?

Chris

> 
> Karel
> 
> On 4/12/22 08:44, Chris Johns wrote:
>> Hi,
>>
>> The following code:
>>
>> // aarch64-rtems6-g++ -std=c++98 -c test.o test.cpp
>> // aarch64-rtems6-g++ -std=c++03 -c test.o test.cpp
>> // aarch64-rtems6-g++ -std=c++11 -c test.o test.cpp
>> // aarch64-rtems6-g++ -std=c++17 -c test.o test.cpp
>> #include 
>> #include 
>> void t1(pthread_t thread) {
>>    ::setenv("ABC", "123", 0);
>>    ::pthread_kill(thread, SIGINT);
>> }
>>
>> produces:
>>
>> $ arm-rtems6-g++ -std=c++17 -c -o test.o test.cpp
>>
>>
>>
>>
>>
>>
>> test.cpp: In function 'void t1(pthread_t)':
>> test.cpp:8:5: error: '::setenv' has not been declared; did you mean 'getenv'?
>>  8 |   ::setenv("ABC", "123", 0);
>>    | ^~
>>    | getenv
>> test.cpp:9:5: error: '::pthread_kill' has not been declared; did you mean
>> 'pthread_key_t'?
>>  9 |   ::pthread_kill(thread, SIGINT);
>>    | ^~~~
>>    | pthread_key_t
>>
>> The same code compiles fine on FreeBSD:
>>
>> $ c++ -std=c++17 -c -o ../test.o ../test.cpp
>>
>>
>>
>>
>>
>>
>> $ c++ --version
>> FreeBSD clang version 6.0.0 (tags/RELEASE_600/final 326565) (based on LLVM 
>> 6.0.0)
>> Target: x86_64-unknown-freebsd11.2
>> Thread model: posix
>> InstalledDir: /usr/bin
>>
>> and Linux:
>>
>> $ g++ -std=c++17 -c -o test.o test.cpp
>> $ g++ --version
>> g++ (Ubuntu 11.2.0-7ubuntu2) 11.2.0
>> Copyright (C) 2021 Free Software Foundation, Inc.
>> This is free software; see the source for copying conditions.  There is NO
>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>>
>> Is there something broken in our newlib?
>>
>> Thanks
>> Chris
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: libc functions from c++ issues

2022-04-12 Thread Karel Gardas




Not sure, but isn't usage of C headers in C++ deprecated for a long time 
now? Shouldn't you use csignal and cstdlib? Newlib provided for RTEMS 
looks to push that even a bit further by providing C++ specific stdlib.h 
(in include/c++ and in include/c++/tr1) which just includes cstdlib and 
exports symbols out from std name space and this way basically hides C 
specific stdlib.h


I'd bet newlib is more correct here, but I'm no expert...

Anyway in the c++/newlib case and if you really insist on c++ compiler 
here, have you tried to use include_next trick by defining 
_GLIBCXX_INCLUDE_NEXT_C_HEADERS? See include/c++/stdlib.h from tools...


Karel

On 4/12/22 08:44, Chris Johns wrote:

Hi,

The following code:

// aarch64-rtems6-g++ -std=c++98 -c test.o test.cpp
// aarch64-rtems6-g++ -std=c++03 -c test.o test.cpp
// aarch64-rtems6-g++ -std=c++11 -c test.o test.cpp
// aarch64-rtems6-g++ -std=c++17 -c test.o test.cpp
#include 
#include 
void t1(pthread_t thread) {
   ::setenv("ABC", "123", 0);
   ::pthread_kill(thread, SIGINT);
}

produces:

$ arm-rtems6-g++ -std=c++17 -c -o test.o test.cpp






test.cpp: In function 'void t1(pthread_t)':
test.cpp:8:5: error: '::setenv' has not been declared; did you mean 'getenv'?
 8 |   ::setenv("ABC", "123", 0);
   | ^~
   | getenv
test.cpp:9:5: error: '::pthread_kill' has not been declared; did you mean
'pthread_key_t'?
 9 |   ::pthread_kill(thread, SIGINT);
   | ^~~~
   | pthread_key_t

The same code compiles fine on FreeBSD:

$ c++ -std=c++17 -c -o ../test.o ../test.cpp






$ c++ --version
FreeBSD clang version 6.0.0 (tags/RELEASE_600/final 326565) (based on LLVM 
6.0.0)
Target: x86_64-unknown-freebsd11.2
Thread model: posix
InstalledDir: /usr/bin

and Linux:

$ g++ -std=c++17 -c -o test.o test.cpp
$ g++ --version
g++ (Ubuntu 11.2.0-7ubuntu2) 11.2.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Is there something broken in our newlib?

Thanks
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

libc functions from c++ issues

2022-04-12 Thread Chris Johns

Hi,

The following code:

// aarch64-rtems6-g++ -std=c++98 -c test.o test.cpp
// aarch64-rtems6-g++ -std=c++03 -c test.o test.cpp
// aarch64-rtems6-g++ -std=c++11 -c test.o test.cpp
// aarch64-rtems6-g++ -std=c++17 -c test.o test.cpp
#include 
#include 
void t1(pthread_t thread) {
  ::setenv("ABC", "123", 0);
  ::pthread_kill(thread, SIGINT);
}

produces:

$ arm-rtems6-g++ -std=c++17 -c -o test.o test.cpp






test.cpp: In function 'void t1(pthread_t)':
test.cpp:8:5: error: '::setenv' has not been declared; did you mean 'getenv'?
8 |   ::setenv("ABC", "123", 0);
  | ^~
  | getenv
test.cpp:9:5: error: '::pthread_kill' has not been declared; did you mean
'pthread_key_t'?
9 |   ::pthread_kill(thread, SIGINT);
  | ^~~~
  | pthread_key_t

The same code compiles fine on FreeBSD:

$ c++ -std=c++17 -c -o ../test.o ../test.cpp






$ c++ --version
FreeBSD clang version 6.0.0 (tags/RELEASE_600/final 326565) (based on LLVM 
6.0.0)
Target: x86_64-unknown-freebsd11.2
Thread model: posix
InstalledDir: /usr/bin

and Linux:

$ g++ -std=c++17 -c -o test.o test.cpp
$ g++ --version
g++ (Ubuntu 11.2.0-7ubuntu2) 11.2.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Is there something broken in our newlib?

Thanks
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: libc functions from c++ issues

Re: libc functions from c++ issues

Re: libc functions from c++ issues

Re: libc functions from c++ issues

Re: libc functions from c++ issues

Re: libc functions from c++ issues

Re: libc functions from c++ issues

libc functions from c++ issues

8 matches

Site Navigation

Mail list logo

Footer information