Re: On the cost of libraries
- From: Colm Smyth <Colm Smyth sun com>
- To: Colm Smyth sun com, dave willfork com
- Cc: dave willfork com, Sander Vesik sun com, dave arsdigita com, otaylor redhat com, alexl redhat com, mjs noisehavoc org, gnome-hackers gnome org
- Subject: Re: On the cost of libraries
- Date: Fri, 16 Nov 2001 10:24:27 +0000 (GMT)
>From: Drazen Kacar <dave willfork com>
>To: Colm Smyth <Colm Smyth sun com>
>
>Colm Smyth wrote:
>> >> It can also be quite handy when trying to resolve
>> >> nasty problems, for example when trying to combine
>> >> two libraries that each expect to be able to override
>> >> the C++ global new() operator, you can specify a different
>> >> "global" new() symbol binding for each library!
>> >
>> >Uh... I think this would backfire sooner or later. How about using -B group
>> >or -z groupperm instead?
>>
>> Why do you think it would backfire? You can't get more explicit than
>> actually stating precisely the library that contains a symbol
>> definition.
>
>Yeah, but... I don't know what would happen if the next installed version
>of that library (binary compatible) just happens not to contain that
>particular symbol. Nothing good, I presume. C++ is not my area and this
>particular example might be safe for all I know. But in general I would
>try to be very cautious with things like that.
Binary compatibility is an important goal, but with C++ it's effectively
impossible; the name-mangling format changes not infrequently, vtable dispatch
is also subject to change. The upshot is that the ABI of a C++ library can
change between minor version updates so the usage scenario I described is
applicable only when you are targetting a well-known C++ ABI.
Colm.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]