This is the mail archive of the
mailing list for the GCC project.
Re: Software Convention Proposal
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Richard Henderson <rth at redhat dot com>, "Kirkegaard, Knud J" <knud dot j dot kirkegaard at intel dot com>, "'gcc at gcc dot gnu dot org'" <gcc at gcc dot gnu dot org>, "Sehr, David C" <david dot c dot sehr at intel dot com>, "Saxena, Sunil" <sunil dot saxena at intel dot com>
- Date: Wed, 21 Aug 2002 22:08:48 +0200
- Subject: Re: Software Convention Proposal
- References: <9795DB627281D941B9E608445730DFC804656D8E@fmsmsx106.fm.intel.com> <20020821190334.GE23736@redhat.com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Wed, Aug 21, 2002 at 12:03:34PM -0700, Richard Henderson wrote:
> A problem area, however, are third-party libraries. In that
> case, given that we cannot modify the headers, the best we can
> do is create a list of the symbols that should be bound a
> particular way and present it to the compiler through some side
> channel. E.g. a file associated with a command line switch.
> > -fprotected -fdefault <file>
> I'm not thrilled about using the same switch to mean two
> different things. Certainly you couldn't just leave the
> filename unassociated like that. So at minimum you'd need
> -fprotected -fdefault=<file>
> But I'd prefer switches that differed slightly. Perhaps
> I'd like input from others on this.
How is this different from just sourcing another header with
#define H(x) extern __typeof(x) x __attribute__((visibility("hidden")));
? The only difference I can think of is if the headers then define
macros with the same names as the functions...