On Wed, 2018-02-07 at 19:26 -0500, Paul Smith wrote:
> Thanks for the conversation. I'm moving forward with a real global
> operator new/delete and working out the magic needed to ensure those
> symbols are not global in our shared library.
I remember one annoying thing I ran into: through compil
On Thu, 2018-02-08 at 01:17 +0100, Marc Glisse wrote:
> On Wed, 7 Feb 2018, Paul Smith wrote:
> > > > My question is, what do I need to do to ensure this behavior
> > > > persists if I create a global operator new/delete?
> > > >
> > > > Is it sufficient to ensure that the symbol for our shared
>
On Wed, 2018-02-07 at 16:38 -0700, Martin Sebor wrote:
> I'm not sure I see how defining operator new inline can work
> unless you recompile the world (i.e., all the DSOs used by
> the program, including libstdc++). As Marc already hinted,
> if libstdc++ dynamically allocates an object using the de
On Wed, 7 Feb 2018, Paul Smith wrote:
My question is, what do I need to do to ensure this behavior
persists if I create a global operator new/delete?
Is it sufficient to ensure that the symbol for our shared library
global new/delete symbols are hidden and not global, using a linker
map or -fvi
On 7 February 2018 at 23:38, Martin Sebor wrote:
> On 02/06/2018 03:56 PM, Paul Smith wrote:
>>
>> Hi all.
>>
>> Hopefully this isn't too annoying a question :).
>>
>> My environment has been using GCC 6.2 (locally compiled) on GNU/Linux
>> systems. We use a separate heap management library (jemal
On 02/06/2018 03:56 PM, Paul Smith wrote:
Hi all.
Hopefully this isn't too annoying a question :).
My environment has been using GCC 6.2 (locally compiled) on GNU/Linux
systems. We use a separate heap management library (jemalloc) rather
than the libc allocator. The way we did this in the pas
On Wed, 2018-02-07 at 11:32 +0100, Marc Glisse wrote:
> On Tue, 6 Feb 2018, Paul Smith wrote:
>
> > My environment has been using GCC 6.2 (locally compiled) on
> > GNU/Linux systems. We use a separate heap management library
> > (jemalloc) rather than the libc allocator. The way we did this in
>
On Tue, 6 Feb 2018, Paul Smith wrote:
My environment has been using GCC 6.2 (locally compiled) on GNU/Linux
systems. We use a separate heap management library (jemalloc) rather
than the libc allocator. The way we did this in the past was to
declare operator new/delete (all forms) as inline fun
Hi all.
Hopefully this isn't too annoying a question :).
My environment has been using GCC 6.2 (locally compiled) on GNU/Linux
systems. We use a separate heap management library (jemalloc) rather
than the libc allocator. The way we did this in the past was to
declare operator new/delete (all fo
