[PATCH] fix sdksyms for gcc3

[Paulo César Pereira de Andrade]

Daniel Stone wrote:
> Hi,

  Hi,

>> extern _X_EXPORT <type-spec><optional-newline> <symbol-name>
>> <ignored...>
>
> I'm pretty troubled by this.  If it's C, then it's C.  If it's not C,
> then it's not C.  Pseudo-C, OTOH ...

  I believe this is one of the possible easiest approaches. The C
source files are filled with symbols defined by macro expansions,
usually generated by multiple inclusion of .c and .h files. So it
should be reasonable to require a "cleanly" specified symbol in
a sdk header. Prepending "extern _X_EXPORT" to declaration of
symbols that should be made available to external (possibly third
party) modules can be seem as a kind of "compromise", but it may
still take some time to have binary, backward compatible modules.
Not in the sense of "encouraging" distribution of binary only
modules, but in the sense of not breaking working code. Luckly
at least for now, binaries for one distro work on another, when
using same kernel and Xorg...

>>   The real problem with "sdksyms.*" is that it is trying to resolve
>> a problem that should not exist in the first place. If the symbols
>> are not "referenced", the linker will not add "unreachable" symbols
>> to the Xorg binary. The problem is that the symbols "dropped" are
>> only reachable from loadable modules.
>>
>>   The proper solution should be either have the Xorg binary actually
>> reference those symbols, or have them in separate modules, or possibly
>> have then in a shared library...
>
> Arguably, the proper solution is an actual (gasp!) linker script to
> manage our so-called API.  Either way, I'm pretty sure that putting half
> of Xorg into a shared library just because we haven't figured out
> linking yet, is not the way forward.

  One could also just pick a few symbols, and "ld -u" them, so that
the linker would not find "unreachable" symbols. sdksyms.* just uses
"another approach", and references all symbols exported in the sdk.
  Actually, since Xorg is already using libtool, it would be just
more practical to also use libtool dependencies. The problem is that
it is kind of a "can of worms", and touching that may cause several
"temporary" problems.

> Cheers,
> Daniel

Paulo