equating symbols to undefined

[H. J. Lu]

On Fri, Oct 21, 2005 at 08:52:37AM +0200, Jan Beulich wrote:
> >> alias.c has to include alias.h according to good programming
> practice,
> >> and suppressing the __asm__-s (which indeed aren't necessary for
> >> alias.c, but also [should] do no harm) would only clutter the
> header
> >> file. Besides this or anything else, this problem is what I'd call
> a
> >> classical regression (because it obviously worked and there was no
> >> notion anywhere that this should not work).
> >
> >I don't think the __asm__ statement belongs to alias.c. It shouldn't
> be
> >there to begin with. The old behavior silently makes a local symbol
> >global. I don't think it is a good idea. Can someone check out other
> >assemblers to see what they do?
> 
> This is not true, the alias symbol remained to be local in the defining
> file with the old behavior. And the alias symbol didn't even appear in
> the symbol table for the consuming file(s).

We can agree to disagree. What do Solaris/HPUX/IRIX/AIX assemblers do
for this case if they support ".set/.equiv/="?

> 
> >> And yes, as agreed to before, .alias would be a lot better suited
> for
> >> this purpose, but we don't have it (yet).
> >
> >I can dig out my old patch and make it generic.
> 
> Which would be useful for the future, but not for code that is expected
> to be buildable not only with the very latest binutils version (i.e. the
> linux kernel, which in the given case is where I ran into the problem).

It just needs to add 2 lines to your alias.h and one line to your
alias.c if you have to include alias.h in alias.c. That will work
will ALL assemblers.


H.J.