Thursday 8 November 2012

The end of the annoying warning

When I upgraded my Gentoo's gcc to 4.5.4, I suddenly started having this spammage of a warning:

file.c:120:1: warning: visibility attribute not supported in this configuration; ignored [-Wattributes]

I immediately thought to myself "oh, how nice, new warnings!" (I'm a warning addict) but didn't pay much attention to it. I also noticed that lots of Gentoo packages were spewing this warning as well, which I started to find suspicious, so I tried fixing them on my own sources to understand the cause of the warning.
It gets generated when I specified the __attribute__((visibility)). Because I generally set the -fdefault-visibility on my make files, pretty much every non-static function was printing out the warning. And I found this rather odd, when building for x86, surely this would be supported on my configuration.

Turns out the "configuration" wasn't my platform at all, it was the result of GCC's "./configure" script:

checking assembler for .hidden... yes
checking linker for .hidden support... no

I wondered why my linker support didn't support the .hidden flag all of a sudden. I had been using the same binutils for a while now and if the previous build of GCC succeeded, why wouldn't this one?
I rebuilt my binutils just to be sure I didn't have any link problems or outdated USE flags, but the configure of gcc still failed.

Eventually I went through the configure scripts themselves and found out that I was using gold (ld.gold) as my linker. I wondered why this would be relevant though, why wouldn't gold support .hidden? But just to be sure, I switched to the bfd linker:

eselect binutils --linker ld.bfd

And behold, the configure script correctly detected the .hidden support by the linker. The warning thus went away. Interestingly, I switched back to the gold linker afterwards and all my projects (along with gentoo packages) that use the .hidden compile fine. I suspect this is a detection problem on GCC's configure script.
Granted, this was with gcc 4.5.4, a more recent version might not have this detection bug.