Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TAO fails to compile using gcc12 #1832

Closed
tmayoff opened this issue May 7, 2022 · 6 comments · Fixed by #1864
Closed

TAO fails to compile using gcc12 #1832

tmayoff opened this issue May 7, 2022 · 6 comments · Fixed by #1864

Comments

@tmayoff
Copy link
Contributor

tmayoff commented May 7, 2022

Version

Master branch (and some of the versions used for OpenDDS)

Host machine and operating system

Fedora 36

Compiler name and version (including patch level)

gcc-12.0.1
clang-14.0.0

The $ACE_ROOT/ace/config.h file

config-linux.h

The $ACE_ROOT/include/makeinclude/platform_macros.GNU file

This was taken from the github workflow

ipv6=1
xerces3=1
ssl=1
INSTALL_PREFIX =/home/tyler/oss/ACE_TAO/installed
CCFLAGS+=-std=c++20
include /home/tyler/oss/ACE_TAO/ACE/include/makeinclude/platform_linux.GNU

AREA/CLASS/EXAMPLE AFFECTED:

Compilation fails here:
../../tao/Any_Insert_Policy_T.h:42:14: error: no viable overloaded '<<='

The problem effects:

Fails to compile

Synopsis

Compilation fails here:
../../tao/Any_Insert_Policy_T.h:42:14: error: no viable overloaded '<<='

Description

There's some more information in this issue on the OpenDDS:
OpenDDS/OpenDDS#3495

Repeat by

Seems to be an issue with gcc12

I'd like to help fix this but I'm not sure how to go about that with this one

@Sascha-Clausen
Copy link

To build and use ACE/TAO with GCC 12 you have to add

#define ACE_ANY_OPS_USE_NAMESPACE

to your ACE/config.h

https://www.gnu.org/software/gcc/gcc-12/changes.html
Two-stage name lookup for dependent operator expressions has been corrected (PR51577)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51577
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51577#c23

@jwillemsen
Copy link
Member

Please open a pull request to add this to the ACE specific config header file and to add gcc12 to github actions CI

@jwillemsen jwillemsen changed the title Fails to compile on Fedora 36 (seems to be gcc12 problem) TAO fails to compile using gcc12 May 29, 2022
@mitza-oci
Copy link
Member

Does anyone have evidence of a build with ACE_ANY_OPS_USE_NAMESPACE working with any currently supported compiler? By working I mean at least compiling all of TAO_ACE.mwc and IDL_Test. Maybe @Sascha-Clausen has some experience with it?

What I'm seeing so far is that there are places in the compiler like be_visitor_array_any_op_ch::visit_array that don't mention ACE_ANY_OPS_USE_NAMESPACE so it seems to be incomplete.

@mitza-oci
Copy link
Member

Does anyone have evidence of a build with ACE_ANY_OPS_USE_NAMESPACE working with any currently supported compiler? By working I mean at least compiling all of TAO_ACE.mwc and IDL_Test. Maybe @Sascha-Clausen has some experience with it?

And I forgot to mention... it may make a difference if versioned namespaces are enabled (MPC feature versioned_namespace=1).

@jwillemsen
Copy link
Member

Not the combination as far as I know, TAOX11 uses versioned namespaces for the core of TAO but that is a limited set of types used and we don't support Solaris/Embarcadero C++ Builder which seem to require ACE_ANY_OPS_USE_NAMESPACE. This feature was added by HP in the past but they also didn't use versioned namespaces

@mitza-oci
Copy link
Member

OK, based on what I learned over the past few days I'm abandoning efforts on ACE_ANY_OPS_USE_NAMESPACE since it was not sufficient to solve the problem and doesn't seem to be necessary either.

Because some overloads of operator<<= are already in ::VERSION_NS::CORBA (or just ::CORBA without the versioned namespace feature) unconditionally (see TAO/tao/AnyTypeCode/SystemExceptionA.h -- not sure if that's a bug or a feature), I'm going to try moving the rest into the same namespace.

When Any_Insert_Policy_Stream<S>::any_insert gets instantiated, the overload resolution for operator<<= should always consider the CORBA namespace since the left-hand-side arg comes from there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging a pull request may close this issue.

4 participants