On 03/30/2017 02:11 AM, Michael Haubenwallner wrote:
When statically linked, shouldn't collect2 add libstdc++'s EH frames to
the main executable's registration table again?
Or is libstdc++'s constructor called instead?
I would think the latter -- because libstdc++ is already linked into a
DSO.
On Thu, Mar 30, 2017 at 4:11 AM, Michael Haubenwallner
wrote:
> On 03/29/2017 10:21 PM, David Edelsohn wrote:
>> On Wed, Mar 29, 2017 at 3:50 PM, Jeff Law wrote:
>>> On 03/27/2017 09:41 AM, David Edelsohn wrote:
>
> As far as I have discovered, the real problem with AIX exception handling
On 03/29/2017 10:21 PM, David Edelsohn wrote:
> On Wed, Mar 29, 2017 at 3:50 PM, Jeff Law wrote:
>> On 03/27/2017 09:41 AM, David Edelsohn wrote:
As far as I have discovered, the real problem with AIX exception handling
is
that the exception landing pads are symbols that must n
On 03/29/2017 03:22 PM, David Edelsohn wrote:
On Wed, Mar 29, 2017 at 5:20 PM, Jeff Law wrote:
On 03/29/2017 02:56 PM, David Edelsohn wrote:
On Wed, Mar 29, 2017 at 4:48 PM, Jeff Law wrote:
On 03/29/2017 02:21 PM, David Edelsohn wrote:
The problem is GCC EH tables and static linking.
On Wed, Mar 29, 2017 at 5:20 PM, Jeff Law wrote:
> On 03/29/2017 02:56 PM, David Edelsohn wrote:
>>
>> On Wed, Mar 29, 2017 at 4:48 PM, Jeff Law wrote:
>>>
>>> On 03/29/2017 02:21 PM, David Edelsohn wrote:
The problem is GCC EH tables and static linking. libstdc++ and the
>>>
On 03/29/2017 02:56 PM, David Edelsohn wrote:
On Wed, Mar 29, 2017 at 4:48 PM, Jeff Law wrote:
On 03/29/2017 02:21 PM, David Edelsohn wrote:
The problem is GCC EH tables and static linking. libstdc++ and the
main application are ending up with two separate copies of the tables
to register E
On Wed, Mar 29, 2017 at 4:48 PM, Jeff Law wrote:
> On 03/29/2017 02:21 PM, David Edelsohn wrote:
>>
>>
>> The problem is GCC EH tables and static linking. libstdc++ and the
>> main application are ending up with two separate copies of the tables
>> to register EH frames.
>>
>> Static linking work
On 03/29/2017 02:21 PM, David Edelsohn wrote:
The problem is GCC EH tables and static linking. libstdc++ and the
main application are ending up with two separate copies of the tables
to register EH frames.
Static linking worked in GCC 4.8, but not in GCC 4.9. I have been
trying to understand
On Wed, Mar 29, 2017 at 3:50 PM, Jeff Law wrote:
> On 03/27/2017 09:41 AM, David Edelsohn wrote:
>>>
>>> As far as I have discovered, the real problem with AIX exception handling
>>> is
>>> that the exception landing pads are symbols that must not (but still are)
>>> exported from shared libraries
On 03/27/2017 09:41 AM, David Edelsohn wrote:
As far as I have discovered, the real problem with AIX exception handling is
that the exception landing pads are symbols that must not (but still are)
exported from shared libraries - even libstdc++.
I'm wondering if attached libtool(!)-patch would f
> As far as I have discovered, the real problem with AIX exception handling is
> that the exception landing pads are symbols that must not (but still are)
> exported from shared libraries - even libstdc++.
>
> I'm wondering if attached libtool(!)-patch would fix even that GDB problem
> once applied
Hi,
as far as I have discovered, the real problem with AIX exception handling is
that the exception landing pads are symbols that must not (but still are)
exported from shared libraries - even libstdc++.
I'm wondering if attached libtool(!)-patch would fix even that GDB problem
once applied to ea
12 matches
Mail list logo
