To fix that bug, grab your as sources, apply the patch, and rebuild gas.
A long explanation of the problem follows.
This is a long-standing problem with gcc that has finally been fixed.
On some architectures, conventions are that C symbols are prepended
an underscore when they get down to assembler, e.g.,
f -> _f
_io -> __io
There is a switch in gcc config files specifically for that, that's
YES_UNDERSCORE.
Unfortunately, gcc used to disregard that switch on i386 for the special
symbol _GLOBAL_OFFSET_TABLE_, so
_GLOBAL_OFFSET_TABLE_ -> _GLOBAL_OFFSET_TABLE_
without any regards for YES_UNDERSCORE setting.
This is a problem for two reasons:
* in a YES_UNDERSCORE world,
GLOBAL_OFFSET_TABLE_ -> _GLOBAL_OFFSET_TABLE_
so you've got a collision. What is worse: _GLOBAL_OFFSET_TABLE_ is reserved
for the implementation, whereas GLOBAL_OFFSET_TABLE_ is not.
* the linker expects __GLOBAL_OFFSET_TABLE_ on OpenBSD arches that prepend
underscores.
Since the bug looked unlikely to get fixed, gas and ld contain some kludges
to alias _GLOBAL_OFFSET_TABLE_ and __GLOBAL_OFFSET_TABLE_.
But the bug has been fixed ! and now, gcc emits __GLOBAL_OFFSET_TABLE_,
which is not recognized by as, as of 2.5. So the fix is simply to make
certain as recognizes the proper spelling __GLOBAL_OFFSET_TABLE_.
For downward compatibility with gcc 2.8.1, as does automagically translates
_GLOBAL_OFFSET_TABLE_ to __GLOBAL_OFFSET_TABLE_, and ld does alias both
symbols to __GLOBAL_OFFSET_TABLE anyhow. Eventually, this downward
compatibility will be removed, and users will be able to use
GLOBAL_OFFSET_TABLE_ in their code.
