Details
Major
Description
MariaDB fails to build on OpenBSD / Bitrig. The code in question utilizes POSIX user contexts which has been made obsolete within POSIX (2001) 12 years ago and was removed from POSIX (2008) 5 years ago.
In file included from /usr/ports/pobj/mariadb-5.5.30/mariadb-5.5.30/mysys/my_context.c:25: /usr/ports/pobj/mariadb-5.5.30/mariadb-5.5.30/include/my_context.h:53:22: error: ucontext.h: No such file or directory /usr/ports/pobj/mariadb-5.5.30/mariadb-5.5.30/mysys/my_context.c: In function 'my_context_spawn_internal': /usr/ports/pobj/mariadb-5.5.30/mariadb-5.5.30/mysys/my_context.c:63: warning: implicit declaration of function 'setcontext' /usr/ports/pobj/mariadb-5.5.30/mariadb-5.5.30/mysys/my_context.c: In function 'my_context_continue': /usr/ports/pobj/mariadb-5.5.30/mariadb-5.5.30/mysys/my_context.c:77: warning: implicit declaration of function 'swapcontext' /usr/ports/pobj/mariadb-5.5.30/mariadb-5.5.30/mysys/my_context.c: In function 'my_context_spawn': /usr/ports/pobj/mariadb-5.5.30/mariadb-5.5.30/mysys/my_context.c:96: warning: implicit declaration of function 'getcontext' /usr/ports/pobj/mariadb-5.5.30/mariadb-5.5.30/mysys/my_context.c:99: error: 'ucontext_t' has no member named 'uc_stack' /usr/ports/pobj/mariadb-5.5.30/mariadb-5.5.30/mysys/my_context.c:100: error: 'ucontext_t' has no member named 'uc_stack' /usr/ports/pobj/mariadb-5.5.30/mariadb-5.5.30/mysys/my_context.c:101: error: 'ucontext_t' has no member named 'uc_link' /usr/ports/pobj/mariadb-5.5.30/mariadb-5.5.30/mysys/my_context.c:106: warning: implicit declaration of function 'makecontext' *** Error 1 in . (mysys/CMakeFiles/mysys.dir/build.make:2520 'mysys/CMakeFiles/mysys.dir/my_context.c.o')
Gliffy Diagrams
Attachments
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
The bug is that new code was added which does not build and is relying upon API which is not guaranteed to be around or even work properly, as has been found on a few Linux architectures by the QEMU guys.
As I said ucontext is obsolete and has been removed from POSIX. OpenBSD / Bitrig do not have ucontext support and it never existed. QEMU for example has a sigaltstack backend for its co-routine support which is used on OpenBSD / Bitrig.
http://git.qemu.org/?p=qemu.git;a=blob;f=coroutine-ucontext.c;h=4bf2cde279b9ccab0d4b5e8b7b18948402a39749;hb=HEAD
http://git.qemu.org/?p=qemu.git;a=blob;f=coroutine-sigaltstack.c;h=3de0bb33bdb511f37b2451d33ed736c61d27425d;hb=HEAD
Thanks for the link to using sigaltstack to setup a new stack. It is interesting, though
not without problems when used in a general library (seems it could conflict if the
signal it uses is also used by the application). The good side is that sigsetjmp()
allows to not save/restore signal mask, which is a performance issue with ucontext.
As I said coroutines is a very important (and underestimated) tool. Just
because POSIX did a mistake and removed support does not mean that the real
world has to follow their insanity. People should not be required to do crazy
hacks like delivering fake signals just to use coroutines. For all its flaws,
ucontext is the portable way to do coroutines and if *BSD chooses not to
support that, that is their problem.
Still, it is a valid feature request to add an option to use sigaltstack for coroutines
in the async client lib part, maybe the problem with signal conflict with the
application can be worked-around somehow? It is not something I will have
time to work on for the foreseeable future though.
Doesn't the GCC inline asm assembly work for OpenBSD/Bitrig? It is faster
than sigaltstack in any case ...
Yes, the x86 GCC inline asm works on x86, but we also support, alpha / arm / hppa / m68k / m88k / mips64 / powerpc / sh / sparc / sparc64.
Kristian, do you think you can quickly add a configure-time check to see what coroutine implementation to use (ucontext, assembly, etc) and disable async library completely if nothing is available?
What is the bug here?
ucontext is the standard way to implement co-routines, it has been available everywhere for ages. Surely OpenBSD has had it for ages also?
Co-routines is an important feature to support for any OS. If Bitrig has removed ucontext for some reason, it needs to provide some other mechanism, and be prepared to port software to use the non-standard mechanism provided, right?
There is an inline assembly implementation available in the source code also, if Bitrig uses the standard register convention it should be usable directly, or it could be modified as appropriate...