http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32219
Mikael Pettersson changed:
What|Removed |Added
CC||mikpe at it dot uu.se
--- Comment #14
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32219
--- Comment #13 from Bernhard Reutner-Fischer
2012-06-28 22:49:52 UTC ---
Created attachment 27716
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27716
testcase
This was (accidentally) fixed on for at least 4.7 ff but without adding a
testc
--- Comment #12 from ncopa at alpinelinux dot org 2010-06-30 11:52 ---
whats the status on this bug? It still happens on gcc-4.4.4.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32219
--- Comment #11 from aldot at gcc dot gnu dot org 2010-03-16 13:35 ---
(In reply to comment #10)
> Well, simply re-ordering the visibility and the weak check in
> varasm.c:default_binds_local_p_1 should do the trick.
>
It does.
http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00665.html
-
--- Comment #10 from rguenth at gcc dot gnu dot org 2010-03-09 12:39
---
Well, simply re-ordering the visibility and the weak check in
varasm.c:default_binds_local_p_1 should do the trick.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |A
--- Comment #9 from aldot at gcc dot gnu dot org 2010-03-08 19:28 ---
(In reply to comment #8)
> What's the status of this bug ?
we currently still end up with
call 0
on e.g. i386
> The same things can happen in libraries with fpic
yes. Thing is that we could theoretically work around
--- Comment #8 from castet dot matthieu at free dot fr 2009-12-29 23:20
---
What's the status of this bug ?
The same things can happen in libraries with fpic
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32219
--- Comment #7 from hjl dot tools at gmail dot com 2008-02-25 22:16 ---
It is a compiler bug after all. From:
http://groups.google.com/group/generic-abi/browse_thread/thread/4364eb484397ebe0
A hidden symbol must be defined in the same component, *if it is
defined at all*. That last p
--- Comment #6 from hjl dot tools at gmail dot com 2008-02-23 23:12 ---
Weak and hidden aren't really compatible. Linker should enforce it.
I opened a linker bug:
http://sourceware.org/bugzilla/show_bug.cgi?id=5789
As for gcc, I think it is OK since it is a user error and linker
should
--- Comment #5 from pluto at agmk dot net 2008-02-23 21:09 ---
(In reply to comment #3)
> (In reply to comment #2)
>
> > Also you should be using -PIE when linking.
>
> hmm, it doesn't work with int main();
>
> $ gcc -s main.c -fpie -Wl,-pie
> /usr/bin/ld: /usr/lib64/crt1.o: relocatio
--- Comment #4 from pluto at agmk dot net 2007-06-05 14:13 ---
(In reply to comment #2)
> f always will bind local ...
so, should gcc reject weak attribute in this (hidden visibility) case?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32219
--- Comment #3 from pluto at agmk dot net 2007-06-05 14:10 ---
(In reply to comment #2)
> Also you should be using -PIE when linking.
hmm, it doesn't work with int main();
$ gcc -s main.c -fpie -Wl,-pie
/usr/bin/ld: /usr/lib64/crt1.o: relocation R_X86_64_32S against
`__libc_csu_fini'
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-05 13:30 ---
f always will bind local ...
Also you should be using -PIE when linking.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32219
--- Comment #1 from pluto at agmk dot net 2007-06-05 12:53 ---
btw, imho the weak+hidden is not a valid combination.
such symbol can't be resolved in runtime because it doesn't exist
in elf rel.plt/rel.dyn tables. it can be resolved only during
linking several objects into one piece (e.g
14 matches
Mail list logo
