Firebird Database Porting progress on haikuos

Firebird Database Porting progress on haikuos

I have defined the platform first to be linux but there are big issues there so next one that i copy pasted is from NetBSD in configure.in


  *-*-haiku*)
    MAKEFILE_PREFIX=netbsd
    PLATFORM=NETBSD
    AC_DEFINE(NETBSD, 1, [Define this if OS is Haiku])
    EDITLINE_FLG=N
    SHRLIB_EXT=so
    ;;


There there are some issues with the ntpl ( posix with pthread but without ntpl ) this is why o get undefined reference to `___tls_get_addr'

/*Thread bug on haiku os */
#undef HAVE___THREAD


next thing that is missing
sys/shm.h

POSIX specification: http://www.opengroup.org/susv3xbd/sys/shm.h.html

Portability problems not fixed by Gnulib:This header file is missing on some platforms: mingw, BeOS.


g++ -I../src/include/gen -I../src/include -I../src/vulcan -DNAMESPACE=Vulcan -O -fno-builtin -DNDEBUG -pipe -MMD -fPIC  -DBOOT_BUILD  -c ../src/jrd/os/posix/isc_ipc.cpp -o ../temp/boot/jrd/isc_ipc.o
../src/jrd/os/posix/isc_ipc.cpp:94: error: 'siginfo_t' has not been declared
../src/jrd/os/posix/isc_ipc.cpp:127: error: 'siginfo_t' has not been declared
../src/jrd/os/posix/isc_ipc.cpp: In function 'bool isc_signal2(int, void (*)(), void*, ULONG)':
../src/jrd/os/posix/isc_ipc.cpp:186: error: 'struct sigaction' has no member named 'sa_sigaction'
../src/jrd/os/posix/isc_ipc.cpp:187: error: 'SA_SIGINFO' was not declared in this scope
../src/jrd/os/posix/isc_ipc.cpp:193: error: 'struct sigaction' has no member named 'sa_sigaction'
../src/jrd/os/posix/isc_ipc.cpp:199: error: 'struct sigaction' has no member named 'sa_sigaction'
../src/jrd/os/posix/isc_ipc.cpp: At global scope:
../src/jrd/os/posix/isc_ipc.cpp:347: error: 'siginfo_t' has not been declared


so i might need to study more about it

System calls from a user program are made in the traditional UNIX way of trapping into the kernel and then jumping to the real code. Since the only way a user program can get into the kernel is via a trap, our kernel is more robust because an errant or malicious program can't just jump into random kernel code and cause damage. The overhead to make a simple system call is quite low, coming in at just over three microseconds.

The mechanism for IPC in UNIX is traditionally through a pipe or the System V shared memory and message routines. The main mechanism for IPC under the Be OS is through named message ports that have a queue for incoming messages. Be message ports are unidirectional, and the incoming queue is limited in size to prevent run-away processes from gobbling all of system memory. We also support shared memory through the create_area() and clone_area() system calls, which allow one process to create an area and another to obtain a mapping to that area. The higher-level library code uses both message ports and shared memory to enable communication between threads in different teams.