[BUG] error in global variables strong aliasing

[Peter S. Mazinger]

On Thu, 20 Apr 2006, Rich Felker wrote:

> On Wed, Apr 19, 2006 at 06:22:46PM -0400, Mike Frysinger wrote:
> > On Tuesday 18 April 2006 19:27, Rich Felker wrote:
> > > On Tue, Apr 18, 2006 at 06:25:38PM -0400, Mike Frysinger wrote:
> > > > > > any problems until after this change ... and really, the alias has
> > > > > > always been weak here, not strong, so you werent revereting anything
> > > > > > when you changed weak_alias(environ) to strong_alias(environ) ...
> > > > > >
> > > > > > if we look at glibc, they never use strong_alias() for data, just
> > > > > > functions
> > > > >
> > > > > I can't find any logic when glibc uses strong_alias versus weak_alias,
> > > > > it seems to me, that anything new added is weak_alias
> > > >
> > > > i was going by a grep of the source code itself ... all aliases used for
> > > > data are weak_alias()
> > >
> > > It would be better to read the fine manuals and learn the semantic
> > > difference between weak and strong and why they're used the way
> > > they're used.
> > 
> > and what manuals would those be exactly ?  we've already shown that 
> > strong_alias() fails to work properly for some architectures regardless of 
> > native or cross-compilation
> > http://sourceware.org/ml/libc-alpha/2006-04/msg00048.html
> > 
> > but if you're implying that we dont understand the difference between a weak 
> > and a strong symbol, you're mistaken
> 
> Sorry, my comment was directed more at Peter. I respect his enthusiasm
> to work on improving uClibc but I often get the feeling that he
> doesn't understand the code he's dealing with and I'd encourage him to
> study the issues in more depth rather than just basing statements on
> what does or does not work experimentally.
> 
> Rich

You are right, I do not understand any of the code I touch ...

None of any manuals will tell you the correct usage of weak v. 
strong within libc (be it glibc or uClibc), the decision we made on this 
list many months ago (search the archives, it was before you were 
around), was to change everything to strong_alias in uClibc, unless not 
needed as weak for some special reason (namely libpthread.so 
requirements). We do not have to do what glibc does (having the same 
function more times and using weak_alias to overcome this problem at link 
time), because we do not compile any duplicates.

Now it turned out that:
1. the toolchain fails to do what it is supposed to under some 
circumstances
2. the decision made about using strong_alias where possible is not 
rendered by 1. invalid, we only have to adapt to the situation the 
toolchain enforces us

Peter

-- 
Peter S. Mazinger <ps dot m at gmx dot net>           ID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2