Bug 436782 – sys-libs/glibc: __clone2 not declared in sched.h on IA64

• Product: Gentoo Linux
• Status: RESOLVED INVALID

[Description Dennis Schridde 2012-10-01 13:28:50 UTC]

__clone2(2) (from sys-apps/man-pages-3.41) claims that sched.h would declare a __clone2 function.

It is exported by the C library:
# scanelf -s __clone2 /lib/libc-2.15.so
 TYPE   SYM FILE 
ET_DYN __clone2 /lib/libc-2.15.so 

But apparently no header declares it:
# grep -R __clone2 /usr/include/
[empty]

While some glibc-2.15 internal header *does* declare it:
# grep -R __clone2 glibc-2.15/
[...]
glibc-2.15/include/sched.h:extern int __clone2 (int (*__fn) (void *__arg), 
void *__child_stack_base,

Reproducible: Always

[Comment 1 Dennis Schridde 2012-10-01 15:57:05 UTC]

tschwinge@freenode#glibc said that it might be necessary to add a "separate sysdeps/unix/sysv/linux/ia64/bits/sched.h, duplicating most of Linux' generic sysdeps/unix/sysv/linux/bits/sched.h". (Just quoting, since I do not know enough about glibc to contribute anything useful there.)

I CC vapier as glibc's IA64 maintainer [1].

[1] http://sourceware.org/glibc/wiki/MAINTAINERS

[Comment 2 SpanKY 2012-10-02 04:52:53 UTC]

i think you misread the man page.  it does not say __clone2 is provided via sched.h, just clone.

note that if you try to use clone directly, ia64 isn't the only odd case you have to handle.  for arches whose stack grows in a different direction (like hppa), you'll need to pass a different value for the stack base.

[Comment 3 Dennis Schridde 2012-10-02 10:47:41 UTC]

(In reply to comment #2)
> i think you misread the man page.  it does not say __clone2 is provided via
> sched.h, just clone.
So I am expected to provide the declaration myself? If so, I'll open a bug on kernel.org against man-pages, to clarify that in the text.

[Comment 4 SpanKY 2012-10-02 16:50:11 UTC]

(In reply to comment #3)

currently, that's how it's always been done.  note that you really really should not be using clone but instead stick to pthreads.  also not that you cannot use clone in a threaded application as you will hit deadlocks (due to glibc itself using locks).

[Comment 5 Dennis Schridde 2012-10-02 17:41:41 UTC]

(In reply to comment #4)
> (In reply to comment #3)
> 
> currently, that's how it's always been done.  note that you really really
> should not be using clone but instead stick to pthreads.  also not that you
> cannot use clone in a threaded application as you will hit deadlocks (due to
> glibc itself using locks).

I am currently trying to get app-emulation/lxc to run here. I'll send them you remarks, once I have a patch ready.

[Comment 6 Andreas K. Hüttel 2017-08-28 21:50:29 UTC]

Since there's no RESOLVED MISUNDERSTANDING ...

Please reopen if there's anything new coming up here.