Change in ld behavior between 2.16.1 and 2.17

Change in ld behavior between 2.16.1 and 2.17

[Albert Chin]

We built gcc-4.0.2 with binutils-2.16 on RHEL4/x86 and gcc-4.0.2 with
native binutils on RHEL5.

When linking a certain C++ program on RHEL4 with our gcc-4.0.2 and
binutils-2.16, we get:
  [1] `.gnu.linkonce.t._ZN3agg18rasterizer_sl_clipINS_12ras_conv_intEE7line_toINS_19rasterizer_cells_aaINS_7cell_aaEEEEEvRT_ii'
  referenced in section `.rodata' of [.a file] defined in discarded section
  `.gnu.linkonce.t._ZN3agg18rasterizer_sl_clipINS_12ras_conv_intEE7line_toINS_19rasterizer_cells_aaINS_7cell_aaEEEEEvRT_ii'
  of [.a file]

Despite this warning, an executable is created. However, when using
the gcc-4.0.2 with native binutils on RHEL5 we get the following:
  [2] `.gnu.linkonce.t._ZN3agg18rasterizer_sl_clipINS_12ras_conv_intEE7line_toINS_19rasterizer_cells_aaINS_7cell_aaEEEEEvRT_ii'
  referenced in section `.rodata' of [.a file] defined in discarded section
  `.gnu.linkonce.t._ZN3agg18rasterizer_sl_clipINS_12ras_conv_intEE7line_toINS_19rasterizer_cells_aaINS_7cell_aaEEEEEvRT_ii'
  of [.a file]
  collect2: ld returned 1 exit status

Trying to narrow this down to either the version of binutils shipping
with RHEL5 or binutils, we built binutils-2.16.1, binutils-2.17, and
binutils-2.18 on both RHEL4 and RHEL5. We then manually linked the
resulting executable with the `ld' generated by binutils-2.16.1,
binutils-2.17, and binutils-2.18. The `ld' generated by
binutils-2.16.1 exhibits the behavior in [1]. The `ld' generated by
binutils-2.17 and binutils-2.18 exhibits the behavior in [2]. So, it
seems the behavior of `ld' changed between binutils-2.16.1 and
binutils-2.17.

Is the behavior in binutils-2.17+ correct? If so, how do we work
around this issue?

-- 
albert chin (china@thewrittenword.com)

Re: Change in ld behavior between 2.16.1 and 2.17

[Alan Modra]

On Wed, Sep 05, 2007 at 12:19:05PM -0500, Albert Chin wrote:
[about references to local symbols in discarded sections causing a
link error]
> Is the behavior in binutils-2.17+ correct?

Well, the linker can't guarantee to fix up the reference to point to
the proper location in the kept section.  Just considering the linker
in isolation, I think it warrants an error.  However, I thought this
gcc bug had been fixed long ago, but if this is occurring with 4.0.2,
perhaps we ought to downgrade the error to a warning again.  (I'm
assuming that the reference was from C++ code rather than assembly,
and that your .a was actually compiled with 4.0.2)

> If so, how do we work around this issue?

Pass --noinhibit-exec to the linker.

-- 
Alan Modra
Australia Development Lab, IBM

Re: Change in ld behavior between 2.16.1 and 2.17

[Albert Chin]

On Sun, Sep 09, 2007 at 02:10:01PM +0930, Alan Modra wrote:
> On Wed, Sep 05, 2007 at 12:19:05PM -0500, Albert Chin wrote:
> [about references to local symbols in discarded sections causing a
> link error]
> > Is the behavior in binutils-2.17+ correct?
> 
> Well, the linker can't guarantee to fix up the reference to point to
> the proper location in the kept section.  Just considering the linker
> in isolation, I think it warrants an error.  However, I thought this
> gcc bug had been fixed long ago, but if this is occurring with 4.0.2,
> perhaps we ought to downgrade the error to a warning again.  (I'm
> assuming that the reference was from C++ code rather than assembly,
> and that your .a was actually compiled with 4.0.2)

It's fixed in gcc-4.1.x and later:
  http://gcc.gnu.org/viewcvs?view=rev&revision=99395

> > If so, how do we work around this issue?
> 
> Pass --noinhibit-exec to the linker.

Thanks.

-- 
albert chin (china@thewrittenword.com)