This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: fix target/15700


On Wed, Mar 16, 2005 at 04:47:21PM -0500, Jakub Jelinek wrote:
> The current approach used e.g. in libxml2 is:
> 
> extern __typeof (xmlXPtrNewRangeNodes) xmlXPtrNewRangeNodes__internal_alias __attribute((visibility("hidden")));
> extern __typeof (xmlXPtrNewRangeNodes) xmlXPtrNewRangeNodes __attribute((alias("xmlXPtrNewRangeNodes__internal_alias")));
> #define xmlXPtrNewRangeNodes xmlXPtrNewRangeNodes__internal_alias
> 
> in a header for all symbols that are supposed to be handled that way.
> This worked in GCC 3.4.x, ATM results in tons of warnings, but still works,
> but once GCC requires the aliases to be defined in the same file
> and visible to GCC, this will not work any longer.

The alias doesn't make sense though.  Note, for instance, that 
you'd get a hard error from the Solaris assembler for this.  I
wish that GAS would do the same thing, but don't really want to
do the work myself.  ;-)

I also prefer the glibc approach because it doesn't require that
we play any games with the preprocessor as with the above.

Assuming that breaking these packages is considered a show-stopper,
what semantics do you suggest for the above alias?  Do we simply
defer the alias indefinitely, waiting for the target symbol to be
defined, and then happily take no action in the case it never does
get defined?  I'd have thought this would be a source of frustration
as well -- a typo in the alias string turns it into a silent no-op.



r~


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]