Your message dated Tue, 18 Sep 2007 09:51:24 +0200 with message-id <[EMAIL PROTECTED]> and subject line Bug#442918: -fvisibility=hidden should not affect symbols declared with extern has caused the attached Bug report 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 I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database)
--- Begin Message ---Package: gcc Version: 4:4.2.1-6 Severity: normal --- Please enter the report below this line. --- If I use -fvisibility=hidden, I expect symbols declared with "extern" not be affected by it, as per the manpage (gcc-4.2 in gcc-4.2-doc). "extern declarations are not affected by -fvisibility, so a lot of code can be recompiled with -fvisibility=hidden with no modifications" Yet a very simple testcase shows that even symbols marked extern are affected. Tested with gcc-4.2, and gcc-4.1. $ cat dso.c extern int symbol(int x); extern int symbol(int x) { } $ gcc -fPIC -DPIC -fvisibility=hidden -shared dso.c -o dso.so && readelf -a dso.so | grep symbol 49: 00000000000004cc 9 FUNC LOCAL HIDDEN 11 symbol If I link an application that uses that symbol, the link will fail, since the symbol is local and hidden. Adding __attribute__((visibility("default"))) works as expected (producing a DEFAULT symbol). Either the manpage, or the behaviour should be changed. Fixing the manpage is for sure the easiest way, but affecting externs symbols by visibility=hidden is nonsense, since those are suppposed to be the API functions that you "export". Its the only (standard) way I can mark a functions as a globally visible API. Also programs using symbols declared as extern expect (and for good reason) to be able to successfully link with a DSO containing that symbol. Alternatives described at http://gcc.gnu.org/wiki/Visibility work of course, but they require code changes. Not at all the "recompile with no modifications" advertised by the manpage. I should have another -fvisibility-hidden-make-extern-behave-the-way-its-supposed-to-be flag if the behaviour for "extern" and -fvisibility=hidden is to stay the same. But if this is to be fixed in the behaviour, then it should be backported to gcc-4.1 too IMHO. --- System information. --- Architecture: amd64 Kernel: Linux 2.6.23-rc6-hrt1-gc87ce658-dirty Debian Release: lenny/sid 500 unstable www.debian-multimedia.org 500 unstable ftp.iasi.roedu.net 500 testing ftp.iasi.roedu.net 500 feisty wine.budgetdedicated.com 500 etch debian.beryl-project.org 1 experimental ftp.iasi.roedu.net --- Package information. --- Depends (Version) | Installed ===========================-+-=============== cpp (>= 4:4.2.1-6) | 4:4.2.1-6 gcc-4.2 (>= 4.2.1-3) | 4.2.1-5
--- End Message ---
--- Begin Message ---=?UTF-8?Q? "T=C3=B6r=C3=B6k?= Edvin" writes: > Package: gcc > Version: 4:4.2.1-6 > Severity: normal > > --- Please enter the report below this line. --- > > If I use -fvisibility=hidden, I expect symbols declared with "extern" > not be affected by it, as per the manpage (gcc-4.2 in gcc-4.2-doc). > > "extern declarations are not affected by -fvisibility, so a lot of > code can be recompiled with -fvisibility=hidden with no modifications" > > Yet a very simple testcase shows that even symbols marked extern are affected. > Tested with gcc-4.2, and gcc-4.1. > > $ cat dso.c > extern int symbol(int x); > extern int symbol(int x) > { > } both the man page and the compiler are correct; remove the definition of `symbol'. extern int symbol(int x); static int foo(int x) { return symbol(x); } $ gcc -fPIC -DPIC -fvisibility=hidden -shared dso.c -o dso.so && readelf -a dso.so | grep symbol 5: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND symbol 55: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND symbol
--- End Message ---
