[ace-users] _XOPEN_SOURCE defined for g++ 3.0.3 on solaris 2. 5.1
Jonathan Wackley
Hi Kitty;
To be absolutely explicit, yes I am compiling natively, and yes I understood
what you said. I was reiterating the situation to understand it better. I
merely verified that the headers do not declare the setreuid function. I
turned on the verbose flag to g++ and found that -
Hi Kitty;
To be absolutely explicit, yes I am compiling natively, and yes I understood
what you said. I was reiterating the situation to understand it better. I
merely verified that the headers do not declare the setreuid function. I
turned on the verbose flag to g++ and found that -D_XOPEN_SOURCE=500 is
defined internally by g++. Other than the option -ansi I could not find a
way to turn it off. It may be defined universally for the multi-standard
interface to gcc libc. Modified OS.i as you suggested, it is a much better
fix. I suspect that gcc was configured on a machine where _XOPEN_SOURCE
made sense, then the compiler is executed on a machine where it does not
make sense. So this is just a nasty work-around. I'm not a gcc/g++ expert
that is why I needed direction. Thanks for your input.
Will have to create debug executable and fill out a bug report if I find
anything significant. The complete method is not returning -1 as expected.
Thanks,
jonw
-----Original Message-----
From: Krishnakumar B
To: Jonathan Wackley
Cc: ace-...@cs.wustl.edu
Sent: 06/05/2002 4:02 PM
Subject: Re: [ace-users] _XOPEN_SOURCE defined for g++ 3.0.3 on solaris
2.5.1
On Monday, 6 May 2002, Jonathan Wackley wrote:
>
> Hi Kitty;
>
> Without the _XOPEN_SOURCE macro undefined in config.h the following
error
> occurs;
>
> g++ -fno-exceptions -W -Wall -Wpointer-arith -pipe -O3 -g
> -fno-implicit-templates -fno-exceptions -fcheck-new -D_REENTRANT
> -I/space2/ace/ACE_wrappers -c -o Basic_Types.o Basic_Types.cpp
> In file included from /space2/ace/ACE_wrappers/ace/OS.h:7934,
> from Basic_Types.cpp:3:
> /space2/ace/ACE_wrappers/ace/OS.i: In static member function `static
int
> ACE_OS::setreuid(long int, long int)':
> /space2/ace/ACE_wrappers/ace/OS.i:10981: `::setreuid' undeclared
(first use
> here)
> /space2/ace/ACE_wrappers/ace/OS.i: In static member function `static
int
> ACE_OS::setregid(long int, long int)':
> /space2/ace/ACE_wrappers/ace/OS.i:10999: `::setregid' undeclared
(first use
> here)
> gmake: *** [Basic_Types.o] Error 1
You didn't get what I said. Maybe I wasn't clear. The headers which ship
with Solaris 2.5.1 doesn't define the prototypes for these functions.
That
is why the ACE_LACKS_SETREUID_PROTOTYPE exists. The question here is
that
why is g++ turning it on a platform which doesn't provide these macros.
So
I asked you if you compiled Solaris 2.5.1 natively. Because I don't see
the
point in g++ turning it on a platform where it is not even defined.
The reason that ACE_LACKS_SETREUID_PROTOTYPE is wrapped inside a #ifdef
is
because on platforms where _XOPEN_SOURCE is defined, these definitions
are
provided directly by the platform and there is no need for us to define
these prototypes. So undefining _XOPEN_SOURCE is not sufficient to fix
your
problem. We need to figure out a way to see if g++ disables defining
this
flag if you compile it on Solaris 2.5.1. In which case, the existing
code
will work fine. If g++ insists on defining _XOPEN_SOURCE
unconditionally,
then we need to hoist the definition of the prototype with a check to
see
if _XOPEN_SOURCE is defined along with __GNUG__ and
ACE_LACKS_SETREUID_PROTOTYPE and make it available to the compiler by
defining it ourselves. Is this clear ?
> Is there something obvious that I'm doing wrong here? I know that my
> includes may be somewhat out of date, it seems though that the
config.h
> that I chose did indicate that setreuid is not declared in standard
> headers and must be declared in OS.i by the
ACE_LACKS_SETREUID_PROTOTYPE
> macro, it does work if the _XOPEN_SOURCE test is made not to exclude
the
> declaration in OS.i
Please see above.
> In SOCK_Connector_Test a connection is attempted with another machine
on
> port 42000, it is assumed that it will fail as no acceptor is on that
> port. The status from the con.complete call is actually 0 where it
should
> be -1. When this happens the log indicates that "Connect which should
> fail didn't", return a false positive return value. This is verified
with
> a telnet to the selected host on port
> 42000. The test to the machine's echo port does connect properly,
again
> verified with telnet command.
>
> if (errno == EWOULDBLOCK || errno == ECONNREFUSED || errno ==
ENETUNREACH)
> {
> if (sock.get_handle () != ACE_INVALID_HANDLE) {
> status = con.complete (sock);
> cout << "status: " << status << endl; // I added this debug
output line,
> jonw
> }
>
> if (status != -1)
> {
> ACE_ERROR ((LM_ERROR,
> ACE_TEXT ("Connect which should fail
didn't\n")));
> status = -1;
> }
> else
> {
> ACE_DEBUG ((LM_DEBUG,
> ACE_TEXT ("%p\n"),
> "SOCK_Connector_Test.cpp" line 180 of 313 --57%-- col 5
>
> I traced it down to (I think) the problem in SOCK_Connector.cpp where
it
> should return an ACE_INVALID_HANDLE in SOCK_Connector::complete as
> remote_sap should be 0 on this call. So it seems that
> ACE::handle_timed_complete should be returning an ACE_INVALID_HANDLE.
AFAICS, I don't see any problems with the test per se. A blocking
connect
is made on the socket. It should fail. And when it fails, we try to
complete the connection, which should fail inside
ACE::handle_timed_complete and we should return from
ACE_SOCK_Connector::complete with a -1 and the test should print proper
fail. If this is not what is happening on your side, I suggest you try
to
run it with a debugger and see what is happening. Unfortunately we don't
test on Solaris 2.5.1 anymore. So if you find any bug or bad behaviour
which should be dealt with by the test, please let us know.
Hope this helps.
-kitty.
--
Krishnakumar B <kitty at cs dot wustl dot edu>
Distributed Object Computing Laboratory, Washington University in
St.Louis
Krishnakumar B
>
> Hi Kitty;
>
> what you said. I was reiterating the situation to understand it better. I
> merely verified that the headers do not declare the setreuid function. I
> turned on the verbose flag to g++ and found that -D_XOPEN_SOURCE=500 is
> defined internally by g++. Other than the option -ansi I could not find a
> way to turn it off. It may be defined universally for the multi-standard
> interface to gcc libc. Modified OS.i as you suggested, it is a much better
> fix.
So far so good.
> I suspect that gcc was configured on a machine where _XOPEN_SOURCE made
> sense, then the compiler is executed on a machine where it does not make
> sense. So this is just a nasty work-around.
If I understand what you are saying, then your version of g++-3.0.3 was
compiled on Solaris 2.6 or later and you are using it on Solaris 2.5.1.
If so, I would recommend not doing that. Which also means that I shouldn't
be touching the files in the CVS repository since the change I suggested is
a local hack which works for you. Is that right ?
> Will have to create debug executable and fill out a bug report if I find
> anything significant. The complete method is not returning -1 as
> expected.
OK.
Jonathan Wackley
I need to followup with the tools group to determine whether it is true or
not. I certainly hope that it was configured and built on a 2.5.1 machine
with a similar set of headers. This being said, I would suspect the gcc
configure and build environment before suspecting the code. If the build
environment is acceptable and it turns outs that your fix is required
generally, I'll let you know.
Thanks again for your help.
jonw
-----Original Message-----
From: Krishnakumar B
To: Jonathan Wackley
Cc: 'ace-...@cs.wustl.edu '
Sent: 06/05/2002 7:34 PM
Subject: RE: [ace-users] _XOPEN_SOURCE defined for g++ 3.0.3 on solaris 2.
5.1