Bug 14654 - gcc does not support the visibility attribute?
Summary: gcc does not support the visibility attribute?
Alias: None
Product: gcc
Classification: Unclassified
Component: c (show other bugs)
Version: 3.3.3
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
Depends on:
Reported: 2004-03-19 15:48 UTC by jkolb
Modified: 2005-07-23 22:49 UTC (History)
3 users (show)

See Also:
Host: i686-pc-linux-gnu
Known to work:
Known to fail:
Last reconfirmed:

gcc compile log. (47.86 KB, application/octet-stream)
2004-03-19 19:32 UTC, jkolb

Note You need to log in before you can comment on or make changes to this bug.
Description jkolb 2004-03-19 15:48:26 UTC
When I try to compile this file:

#include <stdio.h>

void test() __attribute__ ((visibility ("hidden")));

void test() { puts("blah"); }

main(int argc, char **argv)
        return 0;

I get:
test.c: In function `test':
test.c:5: warning: visibility attribute not supported in this configuration; ignored

Also, I cannot build glibc now because it requires the visibility attribute. 
This is stock fsf gcc 3.3.3.

gcc -v
Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.3/specs
Configured with: /usr/src/gcc-3.3.3/configure --host=i686-pc-linux-gnu
--prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man
--enable-threads=posix --enable-languages=c,c++,f77,objc

I compiled it against linux 2.6.3.  There are a few people I know of who have
this issue but we can't figure out why.
Comment 1 Andrew Pinski 2004-03-19 15:56:14 UTC
The reason why it is not supported is because your binutils does not support it, update that and rebuild 
GCC and you will get the attribute visibility working.
Comment 2 jkolb 2004-03-19 15:59:12 UTC
I'm using binutils Which version do i need to update to?
Comment 3 Andrew Pinski 2004-03-19 16:05:17 UTC
Try an official FSF release of 2.14 as is HJL's binutils based on a prelease and is most likely 
not working.  Also make sure that the gcc is finding the right as when configuring gcc.
Comment 4 jkolb 2004-03-19 19:30:30 UTC
Downgraded to binutils 2.14.  Recompiled gcc, and I still get the error.  So I'm
going to revert back to my previous version of binutils.

jkolb@glorfindel:~$ ld --version
GNU ld version 2.14 20030612
Copyright 2002 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License.  This program has absolutely no warranty.

jkolb@glorfindel:~$ uname -a
Linux glorfindel 2.6.3 #1 Tue Mar 9 17:41:38 EST 2004 i686 unknown unknown GNU/Linux
Comment 5 jkolb 2004-03-19 19:32:24 UTC
Created attachment 5947 [details]
gcc compile log.

This is the gcc compile log.
Comment 6 jkolb 2004-03-20 21:18:07 UTC
any thoughts?
Comment 7 Wolfgang Scheicher 2004-03-21 22:49:27 UTC
same problem here. 
downgraded to binutils 2.14 and rebuilt gcc, but no change. 
any idea what else can be the cause? 
Comment 8 jkolb 2004-03-22 21:25:15 UTC
Any help?
Comment 9 jkolb 2004-03-25 06:27:10 UTC
Turns out it's a weird version of coreutils, the problem was happening on
coreutils 5.2.0.  When I upgraded to 5.2.1 and then recompiled binutils and gcc
it went away.
Comment 10 Wolfgang Scheicher 2004-03-25 17:53:33 UTC
after about 20 rebuilds of gcc i found out! 
No - it does not work by simply upgrade coreutils, and it's not a bug in 
it is coreutils which does break it, but it seems to be a chown or something 
like that, because if i do a "export _POSIX2_VERSION=199209" before building 
gcc, everything is fine. 
and one of the new things of coreutils 5.2.0 is that "chown user.group" is 
invalid, a ":" is needed instead of the "." - which can be worked around by the 
export mentioned above. 
sigh - for 2 weeks i had a broken gcc, and trying to track the issue down i 
compleately messed up my system. but now there is light. unfortunately i have 
to do a reinstall now... 
Comment 11 jkolb 2004-03-25 18:00:52 UTC
Then why did mine fix itself? DId you recompile binutils before gcc?  Hm... I
also disabled the other languages (only built c and c++) so maybe that's the
Comment 12 Andrew Pinski 2004-03-25 18:35:55 UTC
It is a bug in coreutils as they should not have gotten ridden of the old options.  We have to 
support targets where "last -n 10" does not work but "last -10" does.