Bug 515700 - Unable to compile due to symbol defined in discarded section
Summary: Unable to compile due to symbol defined in discarded section
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: binutils
Version: rawhide
Hardware: All
OS: Linux
urgent
urgent
Target Milestone: ---
Assignee: Nick Clifton
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: F12Alpha, F12AlphaBlocker f12ffMIA
TreeView+ depends on / blocked
 
Reported: 2009-08-05 12:34 UTC by Jan Horak
Modified: 2013-01-10 05:19 UTC (History)
12 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2009-08-06 22:22:49 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
gnu_unique_test.tar.bz2 (291.08 KB, application/octet-stream)
2009-08-05 19:13 UTC, Jakub Jelinek
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Sourceware 10492 0 None None None Never

Description Jan Horak 2009-08-05 12:34:46 UTC
Description of problem:
The compilation of Firefox in rawhide fails by:

`nsISupports::COMTypeInfo<int>::kIID' referenced in section `.data.rel.ro' of /usr/lib64/xulrunner-sdk-1.9.1/lib/libxpcomglue_s.a(nsGenericFactory.o): defined in discarded section `.rodata._ZN11nsISupports11COMTypeInfoIiE4kIIDE[nsISupports::COMTypeInfo<int>::kIID]' of /usr/lib64/xulrunner-sdk-1.9.1/lib/libxpcomglue_s.a(nsGenericFactory.o)
collect2: ld returned 1 exit status

Version-Release number of selected component (if applicable):
gcc 4.4.1 20090725

Steps to Reproduce:
1. Build firefox package against xulrunner-1.9.1.2-1.fc12 in rawhide
2.
3.
  
Additional info:
Output of nm -C libxpcomglue_s.a (rawhide):
0000000000000000 u nsISupports::COMTypeInfo<int>::kIID
Output of nm -C libxpcomglue_s.a (F11, where compilation is ok):
0000000000000000 V nsISupports::COMTypeInfo<int>::kIID

Same problem also in package mozvoikko: http://koji.fedoraproject.org/koji/taskinfo?taskID=1579946

Comment 1 Lillian Angel 2009-08-05 16:37:23 UTC
Same problem for openjdk: http://koji.fedoraproject.org/koji/taskinfo?taskID=1583668

Comment 2 Jakub Jelinek 2009-08-05 19:11:51 UTC
This seems to be a problem with strip -g on libxpcomglue_s.a and STB_GNU_UNIQUE objects.
At least, when libxpcomglue_s.a isn't stripped, it works fine, when it is, it reports these errors.
I'll attach a testcase, with:
binutils-2.19.51.0.14-30.fc12.x86_64
elfutils-0.142-1.fc12.x86_64
gcc-4.4.1-3.x86_64

I get:

First link
lib.so
First strip -g
Second link
`nsISupports::COMTypeInfo<int>::kIID' referenced in section `.data.rel.ro' of lib.a(libnsGenericFactory.o): defined in discarded section `.rodata._ZN11nsISupports11COMTypeInfoIiE4kIIDE[nsISupports::COMTypeInfo<int>::kIID]' of lib.a(libnsGenericFactory.o)
`nsISupports::COMTypeInfo<int>::kIID' referenced in section `.data.rel.ro' of lib.a(libnsGenericFactory.o): defined in discarded section `.rodata._ZN11nsISupports11COMTypeInfoIiE4kIIDE[nsISupports::COMTypeInfo<int>::kIID]' of lib.a(libnsGenericFactory.o)
`nsISupports::COMTypeInfo<int>::kIID' referenced in section `.data.rel.ro' of lib.a(libnsThreadUtils.o): defined in discarded section `.rodata._ZN11nsISupports11COMTypeInfoIiE4kIIDE[nsISupports::COMTypeInfo<int>::kIID]' of lib.a(libnsThreadUtils.o)
collect2: ld returned 1 exit status
ls: cannot access lib.so: No such file or directory
First eu-strip -g
./test.sh: line 19: 22183 Segmentation fault      eu-strip -g lib.a
Third link
lib.so
Second strip -g
Fourth link
lib.so
./test.sh: line 39: 22328 Segmentation fault      eu-strip -g lib.a

Comment 3 Jakub Jelinek 2009-08-05 19:13:37 UTC
Created attachment 356414 [details]
gnu_unique_test.tar.bz2

Comment 4 Martin Stransky 2009-08-06 08:37:38 UTC
Marked as Alpha 11 blocker.

Comment 5 Jakub Jelinek 2009-08-06 12:09:09 UTC
Simpler testcase:

cat > x.C <<\EOF
template <class T>
struct A
{
  static const int a;
};

template <class T> const int A<T>::a = 16;

#ifdef BAR
# define foo bar
#endif

const int *foo (int i)
{
  static const int *t[] = { &A<int>::a, __null };
  return t[i];
}
EOF
g++ -fpic -c -O2 -o x.o x.C
g++ -fpic -c -O2 -o y.o x.C -DBAR
gcc -shared -nostdlib -o x.so x.o y.o; echo $?
cp -a y.o z.o
strip -g z.o
gcc -shared -nostdlib -o x.so x.o z.o; echo $?

Comment 6 Jakub Jelinek 2009-08-06 12:14:06 UTC
And one where gcc isn't involved:
cat > x.s <<\EOF
	.section	.data.rel.ro,"aw",@progbits
	.align 16
	.type	_ZZ3fooiE1t, @object
	.size	_ZZ3fooiE1t, 16
_ZZ3fooiE1t:
	.quad	_ZN1AIiE1aE
	.quad	0
	.weak	_ZN1AIiE1aE
	.section	.rodata._ZN1AIiE1aE,"aG",@progbits,_ZN1AIiE1aE,comdat
	.align 4
	.type	_ZN1AIiE1aE, @gnu_unique_object
	.size	_ZN1AIiE1aE, 4
_ZN1AIiE1aE:
	.long	16
	.section	.note.GNU-stack,"",@progbits
EOF
sed 's/foo/bar/g' x.s > y.s
as -o x.o x.s
as -o y.o y.s
ld -shared -nostdlib -o x.so x.o y.o; echo $?
cp -a y.o z.o
strip -g z.o
ld -shared -nostdlib -o x.so x.o z.o; echo $?

Comment 7 Jakub Jelinek 2009-08-06 13:39:50 UTC
Fixed binutils built in rawhide, now xulrunner needs to be rebuilt with those binutils.

Comment 8 Bill Nottingham 2009-08-06 14:12:54 UTC
build is: binutils-2.19.51.0.14-31

Comment 9 Jesse Keating 2009-08-06 22:22:49 UTC
This appears to be tagged for the alpha, closing.


Note You need to log in before you can comment on or make changes to this bug.