What's the difference between arch-specific header files of uClib and those header files of linux kernel

Jan-Benedict Glaw jbglaw at lug-owl.de
Mon Mar 26 21:59:54 UTC 2007


On Mon, 2007-03-26 15:57:24 -0400, Rob Landley <rob at landley.net> wrote:
> On Monday 26 March 2007 3:11 pm, Jan-Benedict Glaw wrote:
> > On Mon, 2007-03-26 14:12:54 -0400, Rob Landley <rob at landley.net> wrote:
> > > On Monday 26 March 2007 1:12 pm, Jan-Benedict Glaw wrote:
> > > > Read the postings,
> > > I did.
> > > > I corrected something.
> > > What?
> > That kernel's syscall ABI shouldn't change incompatibly.
> 
> It doesn't.  It never did except via bugs that got fixed.  How does this 
> qualify as you correcting anything or anyone?

You didn't read the mails in this thread. Please do that again?

> Who did you correct?

Myself.

> > Oh, whee, wait...  Ever tried to run the statically linked SETI at home
> > client for linux-alpha?
> 
> The last time I had an alpha working in my presence was 1998, at which time 
> SETI at home didn't exist.  The uClibc ALPHA build has been broken in the 
> nightly builds as long as I can remember, because nobody's bothered to fix 
> it.

Didn't mention uClibc anywhere...

> > Error checking caught it and terminated the 
> > program.
> 
> Ok, I'm presuming that you replaced the kernel and nothing else, when this 
> program stopped working.  So it wasn't that you had a different filesystem 
> with different paths or different file permissions or different user ID or a 
> different IP address or anything that could actually affect the running of 
> the program.

Well, it didn't ever run on a specific machine which I picked. Strace
nicely revealed that it was callins totally bogus syscalls.  In that
time, it was a proprietary client compiled (for "security" reasons) by
Berkeley staff, and IIRC not even open-sources.  Today, they use the
BOINC framework.

> That fact you mention the application as statically linked sort of implies 
> that you DID take it to a different filesystem, which could have all sorts of 
> things different in it unrelated to the kernel.  If you didn't do this, then 
> it wouldn't really matter if it was statically linked or not, no?

Either way:  It used linux-specific syscalls above what OSF used and
these calls got renumbered at some time.

> But giving you the benefit of the doubt for a moment, and before we get to the 
> kernel, let's look at what statically linking doesn't do.  With glibc it 
> doesn't suck in the libnss files, so any attempt to do a dns lookup (which 
> seti at home might very well do) is going to fail, and it can also screw up 

I remember that, right after startup, it was stat'ing some files,
create missing stuff and crashed afterwards, shortly before
downloading further files to work on.

> logins and attempts to look up user information, depending on how things are 
> configured.  And this is assuming that seti at home doesn't dlopen any of its 
> _own_ libraries, which you didn't copy to the new system.

Sure. All well known.

> Now let's look at the kernel.  #1: did your new kernel have a slightly 
> different configuration than the previous one?  #2: did this new kernel have 

Whatever--syscall number shouldn't change.

> a bug that was fixed in future versions?  I can come up with more questions, 
> but this is starting to sound like a "cupholder" tech support call.

Dunno--however, I remember that I tried to start seti at home several
times as newer kernel versions were released.

> You once hit a bug.  You can't be remotely specific about it, and admit you 
> don't know what it actually was, but obviously it proves your point.  Right.

That's > 5 years ago.  All I clearly remember is that strace revealed
a nice bogosity there.

> > That's nothing a statically linked libc could catch, but I 
> > would expect a dynamic version to call the same syscall with different
> > syscall numbers depending on current kernel's version information.
> 
> What you would expect and what reality are has been shown to diverge on 
> multiple occasions.  You have no evidence whatsoever for the above statement, 
> your analysis has a "this guy once said" level of detail, and have carefully 
> placed it into a context in which it can't POSSIBLY be reproduced.
> 
> You are a troll.  I'm going to stop feeding you now.

Well, lets make it EOT here.  If changing reserved field handling and
syscall reordering doesn't fit your interpretation of an ABI that
changed, I'll probably face a hard time putting on better evidence.

I accept being a troll. Thanks.

MfG, JBG

-- 
      Jan-Benedict Glaw      jbglaw at lug-owl.de              +49-172-7608481
 Signature of:                      http://perl.plover.com/Questions.html
 the second  :
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.busybox.net/pipermail/uclibc/attachments/20070326/36651498/attachment-0002.pgp 


More information about the uClibc mailing list