• TAO 6.4.3 & Solaris / developerstudio 12.5

    From Andreas Leitgeb@21:1/5 to All on Fri Jul 28 16:29:33 2017
    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)
  • From Andreas Leitgeb@21:1/5 to Andreas Leitgeb on Fri Jul 28 18:08:20 2017
    Andreas Leitgeb <avl@logic.at> 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)
  • From Andreas Leitgeb@21:1/5 to Andreas Leitgeb on Mon Jul 31 19:37:03 2017
    Andreas Leitgeb <avl@logic.at> 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)
  • From Andreas Leitgeb@21:1/5 to Andreas Leitgeb on Thu Aug 3 19:44:25 2017
    Andreas Leitgeb <avl@logic.at> 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)
  • From Johnny Willemsen@21:1/5 to Andreas Leitgeb on Fri Aug 4 01:51:05 2017
    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 <avl@logic.at> 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)
  • From Johnny Willemsen@21:1/5 to Andreas Leitgeb on Fri Aug 4 01:45:03 2017
    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 <avl@logic.at> 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)
  • From Andreas Leitgeb@21:1/5 to Johnny Willemsen on Fri Aug 4 13:24:30 2017
    Johnny Willemsen <jwillemsen@remedy.nl> 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)
  • From Andreas Leitgeb@21:1/5 to Andreas Leitgeb on Fri Aug 4 20:08:53 2017
    Andreas Leitgeb <avl@logic.at> wrote:
    Johnny Willemsen <jwillemsen@remedy.nl> 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)
  • From David Ryan@21:1/5 to Andreas Leitgeb on Fri Aug 4 12:49:52 2017
    On Friday, August 4, 2017 at 6:28:40 AM UTC-7, Andreas Leitgeb wrote:
    Johnny Willemsen <jwillemsen@remedy.nl> 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)
  • From Andreas Leitgeb@21:1/5 to David Ryan on Fri Aug 4 20:29:48 2017
    David Ryan <djryan7@gmail.com> 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)
  • From Andreas Leitgeb@21:1/5 to Andreas Leitgeb on Fri Aug 4 20:32:14 2017
    Small correction near bottom of quoted text.

    Andreas Leitgeb <avl@logic.at> wrote:
    Andreas Leitgeb <avl@logic.at> wrote:
    Johnny Willemsen <jwillemsen@remedy.nl> 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)
  • From David Ryan@21:1/5 to Andreas Leitgeb on Fri Aug 4 19:36:37 2017
    On Friday, August 4, 2017 at 1:36:23 PM UTC-7, Andreas Leitgeb wrote:
    Small correction near bottom of quoted text.

    Andreas Leitgeb <avl@logic.at> wrote:
    Andreas Leitgeb <avl@logic.at> wrote:
    Johnny Willemsen <jwillemsen@remedy.nl> 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)
  • From Johnny Willemsen@21:1/5 to All on Mon Aug 14 02:28:12 2017
    Hi,

    Andreas Leitgeb <avl@logic.at> wrote:
    Johnny Willemsen <jwillemsen@remedy.nl> 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)
  • From Andreas Leitgeb@21:1/5 to Johnny Willemsen on Tue Aug 15 18:57:04 2017
    Johnny Willemsen <jwillemsen@remedy.nl> wrote:
    Hi,
    Andreas Leitgeb <avl@logic.at> wrote:
    Johnny Willemsen <jwillemsen@remedy.nl> 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)
  • From Johnny Willemsen@21:1/5 to All on Wed Aug 16 02:00:52 2017
    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)