Change in ld behavior between 2.16.1 and 2.17

[Albert Chin <binutils at mlists dot thewrittenword dot com>]

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)