TAO 6.4.3 to be built with developerstudio12.5 (on Oracle Solaris)

In ace/config-lite.h there are two "#if"s that check: __SUNPRO_CC <= 0x5130
The developerstudio12.5's CC has version 0x5140 and it really looks like
it prefers the same treatment as the previous versions.

The symptom of failure (before changing config-lite.h) was that it complained about too few arguments to std::reverse_iterator very early during the build.

After editing ace/config-lite.h (replacing 0x5130 by 0x5140) it got over
that spot and compiling ACE seems to succeed, except that it failed at
some example due to lack of a "GNUmakefile.Svc_Cfg_IPC_Client_Loc_Dgram"

Now, compiling TAO fails at this point:

CC -features=zla -mt -m64 -g -library=Cstd -DACE_HAS_KSTAT -DACE_HAS_CUSTOM_EXPORT_MACROS=0 -D_POSIX_PTHREAD_SEMANTICS -I/rnvs/software/fuer_12.5/ACE_wrappers -DACE_HAS_SCTP -DACE_HAS_LKSCTP -D__ACE_INLINE__ -I../../.. -I../.. -DTAO_HAS_VALUETYPE_OUT_
INDIRECTION -DTAO_PORTABLESERVER_BUILD_DLL -c -KPIC -o .shobj/PolicyS.o PolicyS.cpp
"../../tao/Any_Insert_Policy_T.h", line 42: Error: CORBA::Any::operator<<=(unsigned char) is not accessible from static TAO::Any_Insert_Policy_Stream<unsigned>::any_insert(CORBA::Any*, const unsigned&).
"../../tao/PortableServer/Basic_SArgument_T.cpp", line 103: Where: While instantiating "static TAO::Any_Insert_Policy_Stream<unsigned>::any_insert(CORBA::Any*, const unsigned&)".
"../../tao/PortableServer/Basic_SArgument_T.cpp", line 103: Where: Instantiated from TAO::Ret_Basic_SArgument_T<unsigned, Any_Insert_Policy_Stream>::interceptor_value(CORBA::Any*) const.
Where: Instantiated from non-template code.
1 Error(s) detected.
make[1]: *** [.shobj/PolicyS.o] Error 2
make[1]: Leaving directory `/rnvs/software/fuer_12.5/ACE_wrappers/TAO/tao/PortableServer'

FWIW, a very similar error (but while compiling Servant_Base.cpp
and the wording was "illegal" instead of "not accessible from ...")
happened with that same compiler also on an older version of TAO,
namely 2.2a_p6 .

Maybe I'll followup once I get over that one.


Footnotes:

my ace/config.h:

#include "ace/config-sunos5.11.h"

my include/makeinclude/platform_macros.GNU:

CCFLAGS += -features=zla
ssl = 1
#stlport = 1
buildbits = 64
debug=1 # (or debug=0)
include $(ACE_ROOT)/include/makeinclude/platform_sunos5_sunc++.GNU

Note 1: With stlport=1 active it failed on trying to use
std::allocator_interface
which was still available with solarisstudio12.3, but not any more
with developerstudio12.5 (I don't have 12.4 available to test)
Note 2: -features=zla was added because it compained about invalid empty arrays.

PS: I'm just sharing my experience here. If you think this belongs to
the mailing list, then feel free to forward this post there. (I'm
not on the list, myself.)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Andreas Leitgeb <[email protected]> wrote:

except that it failed at
some example due to lack of a "GNUmakefile.Svc_Cfg_IPC_Client_Loc_Dgram"

Ok, apparently solaris' tar failed to properly unpack the long path names.
(The missing file existed as GNUmakefile.Svc_Cfg_IPC_Client_Loc_Dgra w/o m)
I now unpacked the examples with gnu tar.
So much for that one. The other points of OP still open...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Andreas Leitgeb <[email protected]> wrote:

TAO 6.4.3 to be built with developerstudio12.5 (on Oracle Solaris)

CC -features=zla -mt -m64 -g -library=Cstd -DACE_HAS_KSTAT -DACE_HAS_CUSTOM_EXPORT_MACROS=0 -D_POSIX_PTHREAD_SEMANTICS -I/rnvs/software/fuer_12.5/ACE_wrappers -DACE_HAS_SCTP -DACE_HAS_LKSCTP -D__ACE_INLINE__ -I../../.. -I../.. -DTAO_HAS_VALUETYPE_OUT_

INDIRECTION -DTAO_PORTABLESERVER_BUILD_DLL -c -KPIC -o .shobj/PolicyS.o PolicyS.cpp

"../../tao/Any_Insert_Policy_T.h", line 42: Error: CORBA::Any::operator<<=(unsigned char) is not accessible from static TAO::Any_Insert_Policy_Stream<unsigned>::any_insert(CORBA::Any*, const unsigned&).
"../../tao/PortableServer/Basic_SArgument_T.cpp", line 103: Where: While instantiating "static TAO::Any_Insert_Policy_Stream<unsigned>::any_insert(CORBA::Any*, const unsigned&)".
"../../tao/PortableServer/Basic_SArgument_T.cpp", line 103: Where: Instantiated from TAO::Ret_Basic_SArgument_T<unsigned, Any_Insert_Policy_Stream>::interceptor_value(CORBA::Any*) const.
Where: Instantiated from non-template code.
1 Error(s) detected.
make[1]: *** [.shobj/PolicyS.o] Error 2
make[1]: Leaving directory `/rnvs/software/fuer_12.5/ACE_wrappers/TAO/tao/PortableServer'

Well, no reaction whatsoever, but anyway here's my analysis, in case
someone else hits on it, lateron:

Here is a stripped down and simplified test case, that produces the same
error:

namespace TAO {
class Any;

template < typename > struct Templ { // Any_Insert_Policy_Stream
static inline void foo(Any *p , unsigned x ) { ( * p ) <<= x ; }
};

void operator<<= ( TAO::Any&,unsigned);

class Any {
private:
void operator<<= (unsigned char);
};
}

void foo () {
TAO::Any *a = 0; TAO::Templ<void>::foo(a, 42);
}

Relevant aspects are:
* within namespace "TAO", "Any" is first just declared.

* then a template is defined that uses operator<<= of "Any".
The argument type on the operator<<=-call can be hardcoded.

* then, another overload of the operator is declared, with the
arg-type that was used within the template. If this is moved
before the template, then it compiles fine.

* then, "Any" is defined, and it declares an unused overload of
the operator as private: void operator<<= (unsigned char);

* finally, the template is instantiated. The said compiler only sees
the private operator declared within the class, not the other one.

A quick fix would be to declare the separate operators as "friend"
within class "Any".


I can't judge if this is a bug of the compiler, or TAO relying on
undefined behaviour. If you think this belongs on some ACE/TAO
or the compiler's mailing list, then please forward it there.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Andreas Leitgeb <[email protected]> wrote:

TAO 6.4.3 to be built with developerstudio12.5 (on Oracle Solaris)

Here is a stripped down and simplified test case, that produces the same error:

Here is a slightly more verbose testcase for the compiler regression, that
also shows how it cannot be just worked around (short of major changes to
TAO or at least to tao_idl to produce different code):

https://pastebin.com/UAmsdDin

I'd appreciate feedback if anyone can try to compile either the testcase.cpp
or TAO itself with previous version 12.4 or next version 12.6 of solarisstudio.

A couple of years ago I already tried to compile TAO with 12.4, but back
then the compiler died with some ICE (internal compiler error). I didn't
spend much effort on analyzing, but just stepped back to 12.3, which worked. Have they at least fixed the ICE in the meantime?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

You can always open an issue of pull request at https://github.com/DOCGroup/ACE_TAO. I think most people don't read the newsgroups.

Johnny

On Thursday, August 3, 2017 at 9:48:35 PM UTC+2, Andreas Leitgeb wrote:

Andreas Leitgeb <[email protected]> wrote:

TAO 6.4.3 to be built with developerstudio12.5 (on Oracle Solaris)

Here is a stripped down and simplified test case, that produces the same error:

Here is a slightly more verbose testcase for the compiler regression, that also shows how it cannot be just worked around (short of major changes to
TAO or at least to tao_idl to produce different code):

https://pastebin.com/UAmsdDin

I'd appreciate feedback if anyone can try to compile either the testcase.cpp or TAO itself with previous version 12.4 or next version 12.6 of solarisstudio.

A couple of years ago I already tried to compile TAO with 12.4, but back
then the compiler died with some ICE (internal compiler error). I didn't spend much effort on analyzing, but just stepped back to 12.3, which worked. Have they at least fixed the ICE in the meantime?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

The solaris port isn't actively maintained due to lack of sponsoring. The hardware and software is pretty expensive and we can't buy it without someone sponsoring it. It could be that there is a solution for your problem, but that would need some
sponsoring for time, as you have already found there is a lot of things happening in ACE/TAO. See http://www.remedy.nl for the services of the company I work for.

Johnny

On Thursday, August 3, 2017 at 9:48:35 PM UTC+2, Andreas Leitgeb wrote:

Andreas Leitgeb <[email protected]> wrote:

TAO 6.4.3 to be built with developerstudio12.5 (on Oracle Solaris)

Here is a stripped down and simplified test case, that produces the same error:

Here is a slightly more verbose testcase for the compiler regression, that also shows how it cannot be just worked around (short of major changes to
TAO or at least to tao_idl to produce different code):

https://pastebin.com/UAmsdDin

I'd appreciate feedback if anyone can try to compile either the testcase.cpp or TAO itself with previous version 12.4 or next version 12.6 of solarisstudio.

A couple of years ago I already tried to compile TAO with 12.4, but back
then the compiler died with some ICE (internal compiler error). I didn't spend much effort on analyzing, but just stepped back to 12.3, which worked. Have they at least fixed the ICE in the meantime?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Johnny Willemsen <[email protected]> wrote:

You can always open an issue of pull request at
https://github.com/DOCGroup/ACE_TAO.

Only now I stumbled over the symbol ACE_ANY_OPS_USE_NAMESPACE and
a ChangeLog entry back from Apr 13th 2016. You guys are awesome.

So, my reported "regression" of the compiler appears to be intended
as a "progression" instead (hard to tell just from the symptoms),
and it is in principle covered already.

So, why didn't it work out of the box, then? The answer on that is,
that the symbol ACE_ANY_OPS_USE_NAMESPACE gets (conditionally) defined in config-suncc-common.h (as well as in some other os's headers), but this file itself is not #include'd into any of the config-sunos5.*.h headers.

So, as of now, I'd suggest these changes:

adding config-suncc-common.h (or at least the ACE_ANY_OPS_USE_NAMESPACE)
to config-sunos5.10.h (like how it is already in config-linux.h)
Alternatively, instructions could be updated to suggest including
also config-suncc-common.h into the config.h

changing config-lite.h along "s/0x5130/0x5140/", because the heuristics
for 12.4 (0x5130) appear still necessary for 12.5 (0x5140)
(see the first post of this thread)

reviewing all other places that query the symbol __SUNPRO_CC:
e.g.: orbsvcs/orbsvcs/Event/EC_Basic_Factory.cpp has:
#if defined (__SUNPRO_CC)
// This typedef is a workaround for a SunCC 4.2 bug
typedef ...
#endif
will try to see, if the typedef is still necessary.


I will eventually PR these changes, but would appreciate any feedback
ahead, if any of them is already known or should be fixed differently.

PS: as of writing this, a build with "#define ACE_ANY_OPS_USE_NAMESPACE"
added directly to my config.h is still in progress...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Andreas Leitgeb <[email protected]> wrote:

Johnny Willemsen <[email protected]> wrote:

You can always open an issue of pull request at
https://github.com/DOCGroup/ACE_TAO.

I've just created PR #461 on github.

So, as of now, I'd suggest these changes:
adding config-suncc-common.h (or at least the ACE_ANY_OPS_USE_NAMESPACE)
to config-sunos5.10.h (like how it is already in config-linux.h)

I noticed, that the conditional define for ACE_ANY_OPS_USE_NAMESPACE was originally added in config-sunos5.10.h and then moved to config-suncc-common.h. This "move" should have been a "copy" instead, because config-suncc-common.h isn't included from the config-sunos5.* headers, but sunos definitely needs
the symbol defined for the recent compiler versions.

changing config-lite.h along "s/0x5130/0x5140/", because the heuristics
for 12.4 (0x5130) appear still necessary for 12.5 (0x5140)

added in PR.

reviewing all other places that query the symbol __SUNPRO_CC:
e.g.: orbsvcs/orbsvcs/Event/EC_Basic_Factory.cpp has: [...]

Ignored for now. (at least it didn't matter)

Two more build errors (RND_Timer.cpp and union.idl) showed up, and were
rather easy to fix and are now also included in the PR.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Friday, August 4, 2017 at 6:28:40 AM UTC-7, Andreas Leitgeb wrote:

Johnny Willemsen <[email protected]> wrote:

You can always open an issue of pull request at
https://github.com/DOCGroup/ACE_TAO.

Only now I stumbled over the symbol ACE_ANY_OPS_USE_NAMESPACE and
a ChangeLog entry back from Apr 13th 2016. You guys are awesome.

So, my reported "regression" of the compiler appears to be intended
as a "progression" instead (hard to tell just from the symptoms),
and it is in principle covered already.

So, why didn't it work out of the box, then? The answer on that is,
that the symbol ACE_ANY_OPS_USE_NAMESPACE gets (conditionally) defined in config-suncc-common.h (as well as in some other os's headers), but this file itself is not #include'd into any of the config-sunos5.*.h headers.

So, as of now, I'd suggest these changes:

adding config-suncc-common.h (or at least the ACE_ANY_OPS_USE_NAMESPACE)
to config-sunos5.10.h (like how it is already in config-linux.h)
Alternatively, instructions could be updated to suggest including
also config-suncc-common.h into the config.h

changing config-lite.h along "s/0x5130/0x5140/", because the heuristics
for 12.4 (0x5130) appear still necessary for 12.5 (0x5140)
(see the first post of this thread)

reviewing all other places that query the symbol __SUNPRO_CC:
e.g.: orbsvcs/orbsvcs/Event/EC_Basic_Factory.cpp has:
#if defined (__SUNPRO_CC)
// This typedef is a workaround for a SunCC 4.2 bug
typedef ...
#endif
will try to see, if the typedef is still necessary.

I will eventually PR these changes, but would appreciate any feedback
ahead, if any of them is already known or should be fixed differently.

PS: as of writing this, a build with "#define ACE_ANY_OPS_USE_NAMESPACE"
added directly to my config.h is still in progress...

I noticed that your compiling with -std=Cstd instead of lbistdc++. Doesn't that inhibit you from using C++14 or C++11 features? I was originally configuring mine to compile with -std=c++11 or -std=c++14 in order to link with binaries compatible with GCC
a new feature of Solaris Developer Studio.

Dave

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

David Ryan <[email protected]> wrote:

I noticed that your compiling with -std=Cstd instead of libstdc++. Doesn't that
inhibit you from using C++14 or C++11 features? I was originally configuring mine to compile with -std=c++11 or -std=c++14 in order to link with binaries compatible with GCC a new feature of Solaris Developer Studio.

Originally, I even tried with stlport = 1 in
include/makeinclude/platform_macros.GNU.
That failed, because studio12.5 lacks some class that TAO expected for
stlport mode (iirc, that was allocator_interface). So I removed the stlport option and it picked Cstd instead. I've yet to see how much my own TAO-using application cares - I'll probably need to port that, as well.

Maybe there is another option for C++14 or C++11 features, but I haven't stumbled over it, yet.

I'd be interested in hearing about your result with 12.6.
If you run into troubles, have a look at my PR #461 on github:
https://github.com/DOCGroup/ACE_TAO/pull/461

Maybe, some of the commits will help also for 12.6 - not all
of them may be necessary, and some of them might need another
version bump to deal with 12.6 (probably changing some 0x5140
again to 0x5150 for the pre-processor)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Small correction near bottom of quoted text.

Andreas Leitgeb <[email protected]> wrote:

Andreas Leitgeb <[email protected]> wrote:

Johnny Willemsen <[email protected]> wrote:

You can always open an issue of pull request at
https://github.com/DOCGroup/ACE_TAO.

I've just created PR #461 on github.

So, as of now, I'd suggest these changes:
adding config-suncc-common.h (or at least the ACE_ANY_OPS_USE_NAMESPACE) >> to config-sunos5.10.h (like how it is already in config-linux.h)

I noticed, that the conditional define for ACE_ANY_OPS_USE_NAMESPACE was originally added in config-sunos5.10.h and then moved to config-suncc-common.h.
This "move" should have been a "copy" instead, because config-suncc-common.h isn't included from the config-sunos5.* headers, but sunos definitely needs the symbol defined for the recent compiler versions.

changing config-lite.h along "s/0x5130/0x5140/", because the heuristics
for 12.4 (0x5130) appear still necessary for 12.5 (0x5140)

added in PR.

reviewing all other places that query the symbol __SUNPRO_CC:
e.g.: orbsvcs/orbsvcs/Event/EC_Basic_Factory.cpp has: [...]

Ignored for now. (at least it didn't matter)

Two more build errors (RND_Timer.cpp and union.idl) showed up, and were rather easy to fix and are now also included in the PR.

Sorry, that was class RND_Timer in Random.cpp

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Friday, August 4, 2017 at 1:36:23 PM UTC-7, Andreas Leitgeb wrote:

Small correction near bottom of quoted text.

Andreas Leitgeb <[email protected]> wrote:

Andreas Leitgeb <[email protected]> wrote:

Johnny Willemsen <[email protected]> wrote:

You can always open an issue of pull request at
https://github.com/DOCGroup/ACE_TAO.

I've just created PR #461 on github.

So, as of now, I'd suggest these changes:
adding config-suncc-common.h (or at least the ACE_ANY_OPS_USE_NAMESPACE) >> to config-sunos5.10.h (like how it is already in config-linux.h)

I noticed, that the conditional define for ACE_ANY_OPS_USE_NAMESPACE was originally added in config-sunos5.10.h and then moved to config-suncc-common.h.
This "move" should have been a "copy" instead, because config-suncc-common.h
isn't included from the config-sunos5.* headers, but sunos definitely needs the symbol defined for the recent compiler versions.

changing config-lite.h along "s/0x5130/0x5140/", because the heuristics >> for 12.4 (0x5130) appear still necessary for 12.5 (0x5140)

added in PR.

reviewing all other places that query the symbol __SUNPRO_CC:
e.g.: orbsvcs/orbsvcs/Event/EC_Basic_Factory.cpp has: [...]

Ignored for now. (at least it didn't matter)

Two more build errors (RND_Timer.cpp and union.idl) showed up, and were rather easy to fix and are now also included in the PR.

Sorry, that was class RND_Timer in Random.cpp

It successfully compiled with the -library=CStd which is the normal way to compile if you choose never to use an -std=C++11 or -std=C++14 parameters otherwise it fails miserably. I did have to change the constants for 0x5150 version number.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

Andreas Leitgeb <[email protected]> wrote:

Johnny Willemsen <[email protected]> wrote:

You can always open an issue of pull request at
https://github.com/DOCGroup/ACE_TAO.

I've just created PR #461 on github.

The PR has been integrated and is now part of TAO 2.4.4! See https://swsupport.remedy.nl/news/31-ace-6-4-4-and-tao-2-4-4-released for all release details.

Best regards,

Johnny

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Johnny Willemsen <[email protected]> wrote:

Hi,

Andreas Leitgeb <[email protected]> wrote:

Johnny Willemsen <[email protected]> wrote:

You can always open an issue of pull request at
https://github.com/DOCGroup/ACE_TAO.

I've just created PR #461 on github.

The PR has been integrated and is now part of TAO 2.4.4! See https://swsupport.remedy.nl/news/31-ace-6-4-4-and-tao-2-4-4-released
for all release details.

Thanks for info.


BTW., the page is flagged by firefox as "unsafe". In particular, the
avatar (image from www.gravatar.com) uses an http (no s) url.

It seems like the avatar-url would work with https, too.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

BTW., the page is flagged by firefox as "unsafe". In particular, the
avatar (image from www.gravatar.com) uses an http (no s) url.

It seems like the avatar-url would work with https, too.

Thanks for letting me know, created an internal issue to have someone look into this.

Johnny

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)