01e1343880
A few odds and end fixed with PLIST.template Framework to detect the gas i386 problem Removed bogus patch |
||
---|---|---|
.. | ||
patch | ||
README | ||
test-i386-gas.s |
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.