Linaro GCC packages don't by default use %gnu_unique_object

The example code at http://people.linaro.org/~afrantzis/cpp_unique_global.tar.gz (make; LD_LIBRARY_PATH=. ./main), outputs the same address twice on x86_64, but two different addresses (i.e. there are two different objects) on armhf. On x86_64 the symbol A<int>::a in each .so file is 'u':'unique global', on armhf it is 'w':'weak'. This problem breaks compiz/unity on ARM.

Quoting from Ramana's post in the linaro-toolchain mailing list:

I suspect this is a compiler bug around the handling of STB_GNU_UNIQUE_OBJECT- something I suspect was invented to solve the problem in this space - it should all just work in the GNU/Linux world.

The assembler files on x86_64 from the small testcase have

 .type _ZN1AIiE1aE, @gnu_unique_object

while the one in case of ARM doesn't have this.

However my suspicion about the problem is around the fact that GCC in it's build proces emits .type x, @gnu_unique_object to check whether this feature is supported by the GNU assembler. Historically `@' has been a comment character on ARM . So, the compiler doesn't know that GNU_UNIQUE_OBJECT is supported in the assembler and it all falls apart very quickly after that and therefore doesn't generate such code ...

The quickest workaround IMHO is for a new compiler build that is rebuilt with --enable-gnu-unique-object. Given this feature went into a not very recent version of binutils, I would expect most recent assemblers to support this feature and for this to just work (TM). I would expect this configure option to be turned on for cross-compilers as well. It might also be the fastest way of testing this feature.