Your message dated Thu, 17 Dec 2015 19:47:47 +0100
with message-id <20151217184747.ga16...@aurel32.net>
and subject line Re: Bug#691371: Broken COPY relocation with UNIQUE symbols
(upstream #12510)
has caused the Debian Bug report #691371,
regarding Broken COPY relocation with UNIQUE symbols (upstream #12510)
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
691371: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=691371
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: libc6
Version: 2.13-35
I just rediscovered http://sourceware.org/bugzilla/show_bug.cgi?id=12510 in my
application. Fixed by
http://sourceware.org/git/?p=glibc.git;a=commit;h=028478fa40d85a73b19638dbe3f83b1acebf370c
Attached is the test-case I came up with before I found the commit that fixes
it, and then the upstream bug.
This is a regression in wheezy vs squeeze; gcc in squeeze didn't generate
UNIQUE symbols (at least for this case), AND the old dynamic linker seems to
not have this bug.
The actual code part of that upstream patch applies cleanly to wheezy's libc
and fixes the problem. ISTM that it'd be a good idea to backport, given that
wheezy isn't going to upgrade to a new upstream release.
==== test.h ====
template<typename X>
class Foo {
public:
static const char foo[];
};
==== test1.cpp ====
#include "test.h"
// Creates a UNIQUE symbol (and thus hits dynamic linker bug), used to
// create a WEAK symbol instead.
template<typename X>
const char Foo<X>::foo[] = "string";
template class Foo<int>;
const char * getone() {
// Creates a R_X86_64_GLOB_DAT relocation
return Foo<int>::foo;
}
==== test2.cpp ====
#include "test.h"
#include <stdio.h>
#include <string.h>
int main() {
// Reference creates a R_X86_64_COPY relocation
if (strcmp(Foo<int>::foo, "string")) {
printf("'%s'\n", Foo<int>::foo);
return 1;
}
return 0;
}
==== test.sh ====
g++ -fPIC -shared -o test.so test1.cpp
g++ -o test test2.cpp ./test.so
./test
--- End Message ---
--- Begin Message ---
Version: 2.17-1
On 2012-10-24 16:12, James Y Knight wrote:
> Package: libc6
> Version: 2.13-35
>
> I just rediscovered http://sourceware.org/bugzilla/show_bug.cgi?id=12510 in
> my application. Fixed by
> http://sourceware.org/git/?p=glibc.git;a=commit;h=028478fa40d85a73b19638dbe3f83b1acebf370c
>
> Attached is the test-case I came up with before I found the commit that fixes
> it, and then the upstream bug.
>
> This is a regression in wheezy vs squeeze; gcc in squeeze didn't generate
> UNIQUE symbols (at least for this case), AND the old dynamic linker seems to
> not have this bug.
>
> The actual code part of that upstream patch applies cleanly to wheezy's libc
> and fixes the problem. ISTM that it'd be a good idea to backport, given that
> wheezy isn't going to upgrade to a new upstream release.
>
> ==== test.h ====
> template<typename X>
> class Foo {
> public:
> static const char foo[];
> };
>
> ==== test1.cpp ====
> #include "test.h"
>
> // Creates a UNIQUE symbol (and thus hits dynamic linker bug), used to
> // create a WEAK symbol instead.
> template<typename X>
> const char Foo<X>::foo[] = "string";
> template class Foo<int>;
>
> const char * getone() {
> // Creates a R_X86_64_GLOB_DAT relocation
> return Foo<int>::foo;
> }
>
> ==== test2.cpp ====
> #include "test.h"
> #include <stdio.h>
> #include <string.h>
>
> int main() {
> // Reference creates a R_X86_64_COPY relocation
> if (strcmp(Foo<int>::foo, "string")) {
> printf("'%s'\n", Foo<int>::foo);
> return 1;
> }
> return 0;
> }
>
>
> ==== test.sh ====
> g++ -fPIC -shared -o test.so test1.cpp
> g++ -o test test2.cpp ./test.so
> ./test
This bug has been fixed in upstream glibc 2.14. I am therefore closing
the bug.
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
--- End Message ---