[Bug ld/11175] ld marks destructor hidden global
--- Additional Comments From amodra at gmail dot com 2010-01-15 09:37 --- The sysv gabi says: When the link editor combines several relocatable object files, it does not allow multiple definitions of STB_GLOBAL symbols with the same name. On the other hand, if a defined global symbol exists, the appearance of a weak symbol with the same name will not cause an error. The link editor honors the global definition and ignores the weak ones. Similarly, if a common symbol exists (that is, a symbol whose st_shndx field holds SHN_COMMON), the appearance of a weak symbol with the same name will not cause an error. The link editor honors the common definition and ignores the weak ones. I interpret ignores to mean that whether the weak symbol is present or not, the end result should be the same. So I think HJ's 9670 patch to merge visibilty from the weak symbol to the strong one is totally bogus. -- What|Removed |Added AssignedTo|unassigned at sources dot |amodra at gmail dot com |redhat dot com | Status|NEW |ASSIGNED Last reconfirmed|-00-00 00:00:00 |2010-01-15 09:37:08 date|| http://sourceware.org/bugzilla/show_bug.cgi?id=11175 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/11176] New: error in objdump disassemble for ARM target: ldr addressing mode
On arm Target, the following code: ldrvcsh sp, [pc], #182 ldrvcsh sp, [pc, #182] is disassembled as follow 94: 70dfdbf6ldrvcsh sp, [pc, #182] ; 152 test+0xce 98: 71dfdbf6ldrvcsh sp, [pc, #182] ; 156 test+0xd2 There is an error in handling the addressing mode of the first instruction. regards, -- M. Briday -- Summary: error in objdump disassemble for ARM target: ldr addressing mode Product: binutils Version: 2.17 Status: NEW Severity: normal Priority: P2 Component: binutils AssignedTo: unassigned at sources dot redhat dot com ReportedBy: mikael dot briday at irccyn dot ec-nantes dot fr CC: bug-binutils at gnu dot org GCC target triplet: arm elf http://sourceware.org/bugzilla/show_bug.cgi?id=11176 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/11176] error in objdump disassemble for ARM target: ldr addressing mode
-- What|Removed |Added Severity|normal |minor http://sourceware.org/bugzilla/show_bug.cgi?id=11176 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/11170] error in objdump disassemble for ARM target
--- Additional Comments From nickc at redhat dot com 2010-01-15 11:49 --- Created an attachment (id=4522) -- (http://sourceware.org/bugzilla/attachment.cgi?id=4522action=view) Fix decoding of signed PC offsets -- http://sourceware.org/bugzilla/show_bug.cgi?id=11170 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/11170] error in objdump disassemble for ARM target
--- Additional Comments From nickc at redhat dot com 2010-01-15 11:50 --- Hi Mikaël, Please could you try out the uploaded patch and let me know if it works for you. Cheers Nick -- What|Removed |Added Status|NEW |WAITING http://sourceware.org/bugzilla/show_bug.cgi?id=11170 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/11168] ld.exe CPU time 75 hours
--- Additional Comments From jmihalicza at gmail dot com 2010-01-15 12:07 --- (In reply to comment #3) Crazy C++ templated code take a crazy amount of time to compile/link on my Yes, I agree, this is a separated example, but such things can appear even in real applications when complex metaprograms are used. memory starved machine. This is hardly a ld bug. Memory usage is 22 932 K, peak: 71 152 K. My problem is the lack of scalability. I get objects and assembly code with 'g++ -save-temps' for N = 7 and N = 8. For N = 8 they are cca. 4 times bigger, I would expect ld to run 4 or even 10-20 times longer, but not forever. For N = 7 it is ready in about a minute or less, actually didn't measure the ld phase in itself. For N = 8 it has been running for almost 96 hours now, which would mean a factor of 5700 as a result of 4 times more symbols. I rather believe the process is somehow stuck in an infinite loop. (I know that there can be other factors and the process is not necessarily linear, but the situation is still strange, see also the process properties listed below.) As a comparison I invoked 'nm -C' on the objects and got results in ~5.67s (N=7) and ~189s (N=8), the factor was ~33. I have two snapshots of some process properties: CPU Time 24:20:22 CPU Usage full Mem Usage22 532 K IO Read 6 458 677 777 B IO Write 69 776 456 B IO Other 1 981 332 B CPU Time 95:59:41 CPU Usage full Mem Usage22 932 K Peak 71 152 K IO Read 6 544 941 777 B IO Write149 104 922 B IO Other 1 982 612 B -- What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | http://sourceware.org/bugzilla/show_bug.cgi?id=11168 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/11168] ld.exe CPU time 75 hours
--- Additional Comments From amodra at gmail dot com 2010-01-15 12:39 --- Hmm, OK my guess about memory seems wrong. Please compress and attach the .s file. If you can't do this because even the compressed file is too large, please try binutils-2.20. 2.18 is quite old, and whatever problem you are hitting may already be fixed. -- http://sourceware.org/bugzilla/show_bug.cgi?id=11168 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/11175] ld marks destructor hidden global
--- Additional Comments From hjl dot tools at gmail dot com 2010-01-15 13:13 --- (In reply to comment #2) The sysv gabi says: When the link editor combines several relocatable object files, it does not allow multiple definitions of STB_GLOBAL symbols with the same name. On the other hand, if a defined global symbol exists, the appearance of a weak symbol with the same name will not cause an error. The link editor honors the global definition and ignores the weak ones. Similarly, if a common symbol exists (that is, a symbol whose st_shndx field holds SHN_COMMON), the appearance of a weak symbol with the same name will not cause an error. The link editor honors the common definition and ignores the weak ones. I interpret ignores to mean that whether the weak symbol is present or not, the end result should be the same. So I think HJ's 9670 patch to merge visibilty from the weak symbol to the strong one is totally bogus. Well, is --- extern int foo (void) __attribute__((weak,__visibility__ (hidden))); --- valid or not? -- What|Removed |Added BugsThisDependsOn||9679 http://sourceware.org/bugzilla/show_bug.cgi?id=11175 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/9679] Linker doesn't merge visibility of weak symbol
-- What|Removed |Added OtherBugsDependingO||11175 nThis|| http://sourceware.org/bugzilla/show_bug.cgi?id=9679 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/11175] ld marks destructor hidden global
--- Additional Comments From hjl dot tools at gmail dot com 2010-01-15 13:37 --- In ./libqpe/moc_lnkproperties.o: 140: 000152 FUNCWEAK HIDDEN37 _ZN13LnkPropertiesD1Ev It is ignored only if there is a definition. -- http://sourceware.org/bugzilla/show_bug.cgi?id=11175 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/11175] ld marks destructor hidden global
--- Additional Comments From amodra at gmail dot com 2010-01-15 13:55 --- HJ, I don't understand your point in comment #3. If your 9679 testcase isn't valid C then you had no reason to apply your 9679 patch. If your 9679 testcase is valid (and I think it is), then I believe the link error prior to your 9679 patch is simply due to a gcc bug. gcc ought to only generate an R_X86_64_PC32 reference to a function when the function is known to be local, and since a weak symbol can be overridden there is no guarantee that it is local. In reply to comment #4: Of course. My comment #2 is about the case when a strong global defined symbol exists. -- http://sourceware.org/bugzilla/show_bug.cgi?id=11175 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/11175] ld marks destructor hidden global
--- Additional Comments From hjl dot tools at gmail dot com 2010-01-15 13:56 --- (In reply to comment #1) the testcase is here http://uclibc.org/~kraj/ld-pr11175.tar.bz2 The testcase is invalid. Linker never saw any definition of `LnkProperties::~LnkProperties()'. -- http://sourceware.org/bugzilla/show_bug.cgi?id=11175 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/11175] ld marks destructor hidden global
--- Additional Comments From hjl dot tools at gmail dot com 2010-01-15 14:00 --- (In reply to comment #5) HJ, I don't understand your point in comment #3. If your 9679 testcase isn't valid C then you had no reason to apply your 9679 patch. If your 9679 testcase is valid (and I think it is), then I believe the link error prior to your 9679 patch is simply due to a gcc bug. gcc ought to only generate an R_X86_64_PC32 reference to a function when the function is known to be local, and since a weak symbol can be overridden there is no guarantee that it is local. Symbol visibility was introduced well after weak symbol. I will ask it in gABI group for clarification. -- http://sourceware.org/bugzilla/show_bug.cgi?id=11175 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/11175] ld marks destructor hidden global
--- Additional Comments From amodra at gmail dot com 2010-01-15 14:05 --- In reply to comment #6. Look again. $ nm -o *.o | grep _ZN13LnkPropertiesD1Ev fileselector.o: U _ZN13LnkPropertiesD1Ev lnkproperties.o:0ae9 T _ZN13LnkPropertiesD1Ev moc_lnkproperties.o:0001 W _ZN13LnkPropertiesD1Ev -- http://sourceware.org/bugzilla/show_bug.cgi?id=11175 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/11178] New: Documentation enhancement: option -e
Please add the sentence Note that -e ENTRY does not register ENTRY as an undefined symbol. Use the -u option for that. to the description of -e ENTRY in (ld.info)Options. -- Summary: Documentation enhancement: option -e Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: ld AssignedTo: unassigned at sources dot redhat dot com ReportedBy: konrad dot schwarz at siemens dot com CC: bug-binutils at gnu dot org http://sourceware.org/bugzilla/show_bug.cgi?id=11178 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/11175] ld marks destructor hidden global
--- Additional Comments From hjl dot tools at gmail dot com 2010-01-15 16:01 --- (In reply to comment #8) In reply to comment #6. Look again. $ nm -o *.o | grep _ZN13LnkPropertiesD1Ev fileselector.o: U _ZN13LnkPropertiesD1Ev lnkproperties.o:0ae9 T _ZN13LnkPropertiesD1Ev moc_lnkproperties.o:0001 W _ZN13LnkPropertiesD1Ev Is lnkproperties.o used for linking? -- http://sourceware.org/bugzilla/show_bug.cgi?id=11175 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/11168] ld.exe CPU time 75 hours
--- Additional Comments From jmihalicza at gmail dot com 2010-01-15 16:58
---
I have uploaded the asm and the object to:
http://people.inf.elte.hu/pocok/main2.s.zip
http://people.inf.elte.hu/pocok/main2.o.zip
Both of them are 2MB.
Also I updated my cygwin, from ld the following version was downloaded:
GNU ld (GNU Binutils) 2.19.51.20090704
It produces the bug the same way, main2.{s,o} were generated by the updated
system.
Currenlty:
CPU Time1:45:40
CPU Usage full
Mem Usage72 228 K = peak
IO Read 6 403 080 462 B
IO Write 4 167 731 B
IO Other 1 417 476 B
For N = 7 the whole process including compilation etc completed in 15 seconds.
--
http://sourceware.org/bugzilla/show_bug.cgi?id=11168
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/11175] ld marks destructor hidden global
--- Additional Comments From hjl dot tools at gmail dot com 2010-01-15 17:34 --- (In reply to comment #7) (In reply to comment #5) HJ, I don't understand your point in comment #3. If your 9679 testcase isn't valid C then you had no reason to apply your 9679 patch. If your 9679 testcase is valid (and I think it is), then I believe the link error prior to your 9679 patch is simply due to a gcc bug. gcc ought to only generate an R_X86_64_PC32 reference to a function when the function is known to be local, and since a weak symbol can be overridden there is no guarantee that it is local. Symbol visibility was introduced well after weak symbol. I will ask it in gABI group for clarification. According to discussions on gABI group: http://groups.google.com/group/generic-abi?hl=en GNU linker, gold and Sun linker all merge hidden visibility on weak symbol even when its definition is ignored. Closing as invalid. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||INVALID http://sourceware.org/bugzilla/show_bug.cgi?id=11175 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/11175] ld marks destructor hidden global
--- Additional Comments From raj dot khem at gmail dot com 2010-01-15 18:29 --- (In reply to comment #9) (In reply to comment #8) In reply to comment #6. Look again. $ nm -o *.o | grep _ZN13LnkPropertiesD1Ev fileselector.o: U _ZN13LnkPropertiesD1Ev lnkproperties.o:0ae9 T _ZN13LnkPropertiesD1Ev moc_lnkproperties.o:0001 W _ZN13LnkPropertiesD1Ev Is lnkproperties.o used for linking? yes it is look at the doit.sh script in the testcase. I don't think this can be closed as invalid just yet. There is a global definition for the symbol ~LnkProperties() as seen in lnkproperties.o and linker is making it HIDDEN in the final shared library which is not expected behaviour IMO. On other note this worked before and now it does not so either there has to be other way of doing it or its a regression. If you need to have a look at the sourcecode its here http://people.via.ecp.fr/~clem/nist/doxydoc/allOpie/ -- What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | http://sourceware.org/bugzilla/show_bug.cgi?id=11175 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/11175] ld marks destructor hidden global
--- Additional Comments From raj dot khem at gmail dot com 2010-01-15 18:42 --- after reading the googlegroups thread if ld will propagate most restrictive visibility to the output for a symbol irrespective of its definition then I think this is not what gcc thinks when generating code in this case. The testcase is compiled with -fvisibility-inlines-hidden -- http://sourceware.org/bugzilla/show_bug.cgi?id=11175 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/11175] ld marks destructor hidden global
--- Additional Comments From hjl dot tools at gmail dot com 2010-01-15 19:04 --- Created an attachment (id=4523) -- (http://sourceware.org/bugzilla/attachment.cgi?id=4523action=view) A simple testcase [...@gnu-6 pr11175]$ make cc -fPIC -c -o x.o x.c cc -fPIC -c -o foo.o foo.c cc -fPIC -c -o bar.o bar.c ld -shared -o libx.so foo.o bar.o ld -e main -o x x.o libx.so x.o: In function `main': x.c:(.text+0x5): undefined reference to `foo' make: *** [x] Error 1 [...@gnu-6 pr11175]$ -- http://sourceware.org/bugzilla/show_bug.cgi?id=11175 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/11175] ld marks destructor hidden global
--- Additional Comments From hjl dot tools at gmail dot com 2010-01-15 19:15 --- (In reply to comment #12) after reading the googlegroups thread if ld will propagate most restrictive visibility to the output for a symbol irrespective of its definition then I think this is not what gcc thinks when generating code in this case. The testcase is compiled with -fvisibility-inlines-hidden libqpe isn't built correctly. -- http://sourceware.org/bugzilla/show_bug.cgi?id=11175 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/11175] ld marks destructor hidden global
--- Additional Comments From hjl dot tools at gmail dot com 2010-01-15 19:22 --- `-fvisibility-inlines-hidden' This switch declares that the user does not attempt to compare pointers to inline methods where the addresses of the two functions were taken in different shared objects. The effect of this is that GCC may, effectively, mark inline methods with `__attribute__ ((visibility (hidden)))' so that they do not appear in the export table of a DSO and do not require a PLT indirection when used within the DSO. Enabling this option can have a dramatic effect on load and link times of a DSO as it massively reduces the size of the dynamic export table when the library makes heavy use of templates. Is LnkProperties::~LnkProperties() inlined? -- http://sourceware.org/bugzilla/show_bug.cgi?id=11175 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/11175] ld marks destructor hidden global
--- Additional Comments From raj dot khem at gmail dot com 2010-01-15
21:37 ---
(In reply to comment #15)
`-fvisibility-inlines-hidden'
This switch declares that the user does not attempt to compare
pointers to inline methods where the addresses of the two functions
were taken in different shared objects.
The effect of this is that GCC may, effectively, mark inline
methods with `__attribute__ ((visibility (hidden)))' so that
they do not appear in the export table of a DSO and do not require
a PLT indirection when used within the DSO. Enabling this option
can have a dramatic effect on load and link times of a DSO as it
massively reduces the size of the dynamic export table when the
library makes heavy use of templates.
Is LnkProperties::~LnkProperties() inlined?
Its in the class in lnkproperties.h but defined in lnkproperties.cpp file
LnkProperties::~LnkProperties()
{
}
--
http://sourceware.org/bugzilla/show_bug.cgi?id=11175
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/11175] ld marks destructor hidden global
-- What|Removed |Added Attachment #4523|application/octet-stream|application/x-bzip mime type|| http://sourceware.org/bugzilla/show_bug.cgi?id=11175 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/11175] ld marks destructor hidden global
--- Additional Comments From hjl dot tools at gmail dot com 2010-01-15
22:11 ---
(In reply to comment #16)
(In reply to comment #15)
`-fvisibility-inlines-hidden'
This switch declares that the user does not attempt to compare
pointers to inline methods where the addresses of the two functions
were taken in different shared objects.
The effect of this is that GCC may, effectively, mark inline
methods with `__attribute__ ((visibility (hidden)))' so that
they do not appear in the export table of a DSO and do not require
a PLT indirection when used within the DSO. Enabling this option
can have a dramatic effect on load and link times of a DSO as it
massively reduces the size of the dynamic export table when the
library makes heavy use of templates.
Is LnkProperties::~LnkProperties() inlined?
Its in the class in lnkproperties.h but defined in lnkproperties.cpp file
LnkProperties::~LnkProperties()
{
}
Please find out how it became` hidden and weak:
140: 000152 FUNCWEAK HIDDEN37 _ZN13LnkPropertiesD1Ev
in ./libqpe/moc_lnkproperties.o.
--
http://sourceware.org/bugzilla/show_bug.cgi?id=11175
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/11175] ld marks destructor hidden global
--- Additional Comments From raj dot khem at gmail dot com 2010-01-16 00:25 --- Created an attachment (id=4524) -- (http://sourceware.org/bugzilla/attachment.cgi?id=4524action=view) preprocessed testcase -- http://sourceware.org/bugzilla/show_bug.cgi?id=11175 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/11175] ld marks destructor hidden global
--- Additional Comments From hjl dot tools at gmail dot com 2010-01-16 00:41 --- (In reply to comment #19) (In reply to comment #18) Created an attachment (id=4524) -- (http://sourceware.org/bugzilla/attachment.cgi?id=4524action=view) preprocessed testcase -fvisibility-inlines-hidden is making this difference. $ arm-oe-linux-gnueabi-g++ -c -fvisibility-inlines-hidden moc_lnkproperties.i $ readelf -s moc_lnkproperties.o |grep ZN13LnkPropertiesD1Ev 298: 136 FUNCWEAK HIDDEN 154 _ZN13LnkPropertiesD1Ev $ arm-oe-linux-gnueabi-g++ -c moc_lnkproperties.i $ readelf -s moc_lnkproperties.o |grep ZN13LnkPropertiesD1Ev 298: 136 FUNCWEAK DEFAULT 154 _ZN13LnkPropertiesD1Ev ~LnkProperties() isn't in moc_lnkproperties.i. gcc generates it and marks it hidden. You should add ~LnkProperties (); to class LnkProperties declaration so that gcc won't mark it hidden. -- What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID http://sourceware.org/bugzilla/show_bug.cgi?id=11175 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/11175] ld marks destructor hidden global
--- Additional Comments From raj dot khem at gmail dot com 2010-01-16 00:27 --- (In reply to comment #18) Created an attachment (id=4524) -- (http://sourceware.org/bugzilla/attachment.cgi?id=4524action=view) preprocessed testcase -fvisibility-inlines-hidden is making this difference. $ arm-oe-linux-gnueabi-g++ -c -fvisibility-inlines-hidden moc_lnkproperties.i $ readelf -s moc_lnkproperties.o |grep ZN13LnkPropertiesD1Ev 298: 136 FUNCWEAK HIDDEN 154 _ZN13LnkPropertiesD1Ev $ arm-oe-linux-gnueabi-g++ -c moc_lnkproperties.i $ readelf -s moc_lnkproperties.o |grep ZN13LnkPropertiesD1Ev 298: 136 FUNCWEAK DEFAULT 154 _ZN13LnkPropertiesD1Ev -- http://sourceware.org/bugzilla/show_bug.cgi?id=11175 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/11175] ld marks destructor hidden global
--- Additional Comments From hjl dot tools at gmail dot com 2010-01-16
01:06 ---
Here is a testcase:
[...@gnu-6 pr11175]$ cat z.cc
class QObject
{
public:
virtual ~QObject();
virtual const char *className() const;
};
class LnkProperties : public QObject
{
public:
const char *className() const;
};
const char *LnkProperties::className() const
{
return LnkProperties;
}
[...@gnu-6 pr11175]$ gcc -S z.cc -fvisibility-inlines-hidden;
[...@gnu-6 pr11175]$ grep _ZN13LnkPropertiesD2Ev z.s | grep hidden
.hidden _ZN13LnkPropertiesD2Ev
[...@gnu-6 pr11175]$
You can't have a different declaration of class LnkProperties with user
defined:
LnkProperties::~LnkProperties()
{
}
--
http://sourceware.org/bugzilla/show_bug.cgi?id=11175
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
