[omniORB] [External] Re: OmniORB-4.2.2 compiled with gcc8 and C++14 leads into crash
Prasath_Palaniappan at amat.com
Prasath_Palaniappan at amat.com
Mon Apr 15 09:26:39 BST 2019
Hi Duncan,
Gentle Reminder. We are waiting for your guidance.
Thanks & Regards,
P. Prasath.
_____________________________________________
From: Prasath Palaniappan
Sent: Wednesday, April 10, 2019 4:34 PM
To: Duncan Grisby <duncan at grisby.org>; omniorb-list at omniorb-support.com
Cc: Shankar Chinnusamy <Shankar_Chinnusamy at amat.com>; Sendil Natarajan <Sendil_Natarajan at amat.com>
Subject: RE: [External] Re: [omniORB] OmniORB-4.2.2 compiled with gcc8 and C++14 leads into crash
Hi Duncan,
Thanks for your guidance.
I described here what we need to proceed further.
Our Requirement:
As you aware we have been using OmniORB-4.2.2 which is compiled with “gcc4.8 and C++14”.
Moving forward we will be using “gcc8 and C++17”.
So, we are in need to compile and use the OmniORB-4.2.2 with "gcc8 and C++17".
What we did:
OmniORB-4.2.2 has dynamic exception specifications those are unsupported in C++17.
So we removed those unsupported dynamic exception specifications and compiled the OmniORB-4.2.2 with "gcc8 and C++17".
virtual void visit(const char* value,Source source) throw (BadParam) = 0;
Apart from those changes what else need to be done to compile the OmniORB-4.2.2 with "gcc8 and C++17" properly?
Clarifications:
As you mentioned that you have removed throw specifications in OmniORB-4.3 to support future compilers and it is in development branch. If so, could you please let us know when it will be released?
If it will take more time to release, Could you please provide that what are the changes need to be done in OmniORB-4.2.2 to support C++17 without any issue?
It would be good if you can share the changes what has been done in OmniORB-4.3 over OmniORB-4.2.x to support future compiler as a patch file?
Thanks & Regards,
P. Prasath.
-----Original Message-----
From: Duncan Grisby <duncan at grisby.org<mailto:duncan at grisby.org>>
Sent: Friday, March 29, 2019 7:44 PM
To: Prasath Palaniappan <Prasath_Palaniappan at amat.com<mailto:Prasath_Palaniappan at amat.com>>; omniorb-list at omniorb-support.com<mailto:omniorb-list at omniorb-support.com>
Cc: Shankar Chinnusamy <Shankar_Chinnusamy at amat.com<mailto:Shankar_Chinnusamy at amat.com>>; Sendil Natarajan <Sendil_Natarajan at amat.com<mailto:Sendil_Natarajan at amat.com>>
Subject: Re: [External] Re: [omniORB] OmniORB-4.2.2 compiled with gcc8 and C++14 leads into crash
CAUTION: EXTERNAL EMAIL. Verify before you click links or open attachments. Questions? Contact GIS.
On Fri, 2019-03-29 at 13:37 +0000, Prasath_Palaniappan at amat.com<mailto:Prasath_Palaniappan at amat.com> wrote:
> > You need to figure out why your build broke the exception handling:
>
> Dynamic exception specification throw(type) is deprecated in C++17
> https://en.cppreference.com/w/cpp/language/except_spec
>
> When compiled the OmniORB-4.2.2 source with “gcc8 and C++17”, we
> resolved the compilation errors related to dynamic exception
> specifications those are unsupported in C++17. Mentioned few headers
> below, virtual void visit(const char* value,Source source) throw
> (BadParam) = 0;
That is a totally unrelated area of the code. Those throw specifications have already been removed from the omniORB 4.3 development branch, but they cannot be removed from 4.2.x because that could break binary library compatibility in some environments.
Whether you have removed those throw specifications from your code or not will have absolutely no bearing on the problem you are seeing, because your situation does not involve those functions or those exceptions. The functions and exceptions involved in the error you see do not have throw specifications.
omniORB's code is throwing giopStream::CommFailure. Higher up the call chain there are exception handlers for that, and your own testing shows that the exceptions are caught and handled fine when the code is compiled with a different compiler. For some reason it does not work with your newer compiler. I don't know why not, but it is not a problem in omniORB's code. It is a problem in your compiler or runtime environment.
Duncan.
--
-- Duncan Grisby --
-- duncan at grisby.org<mailto:duncan at grisby.org> --
-- http://www.grisby.org --
The content of this message is APPLIED MATERIALS CONFIDENTIAL. If you are not the intended recipient, please notify me, delete this email and do not use or distribute this email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20190415/d810fccd/attachment.html>
More information about the omniORB-list
mailing list