On Sat, Jan 03, 2009 at 04:21:19AM -0200, Paulo César Pereira de Andrade wrote:
> Daniel Stone wrote:
> >> extern _X_EXPORT
> >>
> >
> > 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 eas
Daniel Stone wrote:
> Hi,
Hi,
>> extern _X_EXPORT
>>
>
> 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 expan
Hi,
On Fri, Jan 02, 2009 at 09:14:42AM -0200, Paulo César Pereira de Andrade wrote:
> I don't want to have it in any intrusive or hard to understand
> way. But to allow easier handling by automated tools, the syntax
> for symbols that should be available to modules is:
>
> extern _X_EXPORT
Matthieu Herrb wrote:
> gcc 3.3 (at least) doesn't support visibility attributes, so _X_EXPORT
> expands to nothing. This breaks the awk script embedded in
> hw/xfree86/loader/sdksyms.sh that expects that an extern function
> declaration to be in the form "extern __attribute__(___something___)
> ty
gcc 3.3 (at least) doesn't support visibility attributes, so _X_EXPORT
expands to nothing. This breaks the awk script embedded in
hw/xfree86/loader/sdksyms.sh that expects that an extern function
declaration to be in the form "extern __attribute__(___something___)
type ..."
With the attached patch
