Bug 191618 - .rodata reference to symbol defined in discarded section
Summary: .rodata reference to symbol defined in discarded section
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: compat-gcc-32   
(Show other bugs)
Version: 5
Hardware: All Linux
medium
medium
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-05-13 21:43 UTC by Miles Sabin
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-05-14 16:59:08 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Miles Sabin 2006-05-13 21:43:00 UTC
Description of problem:

When building a C++ application with g++32 I get linker errors of the form,

  `.gnu.linkonce.t.[symbol]' referenced in section `.rodata' of [file].o:
defined in discarded section `.gnu.linkonce.t.[symbol]' of [file].o

The particular cases I have are inlined functions from the boost date_time
library which should be being inlined to the extent that it's unnecessary to
link against libboost_date_time.so.

The same application compiles and links without error using
binutils-2.15.94.0.2.2-2.1 and the compat-* packages from FC4.

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

2.16.91.0.6-5

How reproducible:

Always

Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 Jakub Jelinek 2006-05-14 16:59:08 UTC
compat-gcc* is provided as is, so bugs like this (which is indeed gcc bug, but
binutils) that were present in earlier versions will be present even in the
versions where it is provided as compatibility package.

Comment 2 Miles Sabin 2006-05-18 07:35:09 UTC
I understand the need to preserve backwards compatability here. The problem is
that there's been a change in behaviour with FC5. With FC4 this is reported as a
warning, but the build completes and I get a binary which works on FC3/4/5 and
RHEL 3/4. With FC5 the build just fails.



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