Re: [boost] [utility] Proposal to extract some components from Boost.Log

Subject: Re: [boost] [utility] Proposal to extract some components from Boost.Log
From: Petr Machata (pmachata_at_[hidden])
Date: 2013-08-28 19:50:52

Antony Polukhin <antoshkka_at_[hidden]> writes:

>> > GCC's Standard library and some other libraries had an issue. They
>> > were assuming that if two dynamic libraries have same strings, then
>> > dynamic linker will load those symbols to the same address. That's
>> > why they were comparing types by pointers to type names instead of
>> > comparing type names.  Unfortunately assumption is not right for
>> > some platforms (ARM) and linkers.
>
> Oh yes, I'll need to check GCC once more. As I remember that issue was
> fixed in GCC 4.5 and it is safe to use default std::type_info
> comparison.

If the following would reproduce the problem, then it has been fixed on
ARM by now:

[petr_at_trimslice-f18-v7hl tmp]$ cat lib.cc
#include <typeinfo>
class xx {};
std::type_info const &get_ti () {
  return typeid (xx);
}

[petr_at_trimslice-f18-v7hl tmp]$ g++ lib.cc -Wall -fpic -shared -o lib.so
[petr_at_trimslice-f18-v7hl tmp]$ cat app.cc
#include <cassert>
#include <typeinfo>
class xx {};
std::type_info const &get_ti ();

int main (void) {
  std::type_info const &ti1 = get_ti ();
  std::type_info const &ti2 = typeid (xx);
  assert (&ti1 == &ti2);
  assert (ti1.name () == ti2.name ());
}

[petr_at_trimslice-f18-v7hl tmp]$ g++ app.cc lib.so -Wall
[petr_at_trimslice-f18-v7hl tmp]$ LD_LIBRARY_PATH=. ./a.out 
[petr_at_trimslice-f18-v7hl tmp]$ echo $?
0
[petr_at_trimslice-f18-v7hl tmp]$ rpm -q gcc glibc
gcc-4.7.2-8.fc18.armv7hl

However that might also be influenced by the dynamic linker, as that's
where vague linkage is resolved.  I don't know about this particular
problem, so I don't know what it was caused by.

Thanks,
PM