Public SourceMage Discussion List

[Arwed von Merkatz <v.merkatz AT gmx.net>]

On Wed, Nov 10, 2004 at 10:49:37AM +0100, Benoit PAPILLAULT wrote:
> Arwed von Merkatz a écrit :
> >>Since you persist on your solution, here are few drawbacks:
> >>- /lib is hardcoded. So this fix will not correctly work on bi-arch or 
> >>multi-arch platform.
> >
> >Then give me the info that's needed to make the function work on those.
> 
> Use getconf GNU_LIBPTHREAD_VERSION.

Guess I'll add that as the primary check in the glibc_is_nptl function
then.

> >>- libc.so.6 is hardcoded. So this fix might not work on all platforms.
> >
> >It works on all platforms we have, otherwise someone would have filed a
> >bug about it much earlier, those checks have been there for over a year.
> >
> >>- hardcoded values are just leading to more bugs each time they changed.
> >
> >That's why I made it a function, so it can easily be adjusted if it's
> >still needed when glibc changes again.
> >
> >
> >>- I think it should be "if grep -q NTPL /lib/libc.so.6; then". This code 
> >>does not work. You've never tested it (even if perforce is out of date, 
> >>someone commited at one time a non working, non tested code).
> >>So now, just tell me what's wrong with patching glibc and mysql spells 
> >>(and other spells that might need it)? It's your turn :-)
> 
> Sorry here. I did not know that you can execute /lib/libc.so.6 (and a 
> quick check on my debian system say that such file is not executable 
> here). I did not know that executing /lib/libc.so.6 produces something 
> (apparently it's configuration). It seems to be the same as getconf's 
> output btw. Is there a place where this is documented btw?

Odd that it wouldn't be executable on debian, it's always been
executable on smgl and I tried that some days ago on RedHat and SuSE too
and it worked (though its output was just plain wrong on RedHat, it was
a NPTL glibc that output linuxthreads when executed).
Not sure if it's documented somewhere, I don't even remember who used
that way to check first and where the info came from.

> >Nothing is wrong with that, but fixing upstream software to work takes
> >time I don't have, and the way I did it works _now_. If someone takes
> >the time to fix the other software that needs the NPTL check right now
> >to work correctly (and sends that fix upstream), I'll happily remove the
> >function again.
> 
> I was just talking about existing patchs. And I thought reporting bugs 
> and fixing upstream software was a lot better than making changes on the 
> distro side (versus the upstream software side).
 
Existing patches can be applied, sure.
Upstream bugs related to packaging (or anything else for that matter)
should definitely be reported, but quite some projects don't care too much
about problems with packaging, they just assume distros can fix them, so
sometimes we just have to live with patching stuff to work.

-- 
Arwed v. Merkatz                              Source Mage GNU/Linux developer
                                                    http://www.sourcemage.org