Hi everyone,

I am just looking into the SDK and I have some questions.
If I want to port some Unix/Linux tool, what am I supposed to choose, ixemul or libnix?
According to documents ixemul is more POSIX compliant than libnix, but looking at the different includes I find signal.h in "include" is missing a lot compared to FreeBSD 12 and semaphore.h is not available, but available in includestd.
Does this mean that semaphores are not available in ixemul and signal handling is limited in ixemul? Or is includestd not for libnix?

Can I mix both inside a project, e.g. compile some modules with libnix support and link this together with ixemul modules to an executable?

Also gcc seems to have problems linking with -pie, as it claims pie is not available. Is this a general MOS thing and -fPIC, -pie,... needs to be removed when compiling?

Quote:
ixemul, assuming you just want to quickly get things done.

Usually "proper" ports will use libnix, but this is quite often overkill just to get something done quickly.

Quote:
The ixemul API is unfortunately rather old but slowly getting upgraded. Next SDK will also include semaphore.h for ixemul, as well as accompanying libpthtread.a. Much of the time many GNU projects have some support library that implements the necessary functionality using the functions that are available (typically this is called libgnu.a). This works remarkably well. Sometimes some small patches are needed to avoid some missing functions.

Quote:
The semaphore implementation is missing in the current public SDK, but will be part of the next SDK release. Signal handling is limited, but exists and is working (with certain limitations such as for example KILL not being possible). Typically the missing functions can be implemented with the existing rudimentary functions. If you have any specific needs or something critical missing let me know and I'll look into adding it.

Quote:
includestd is libnix, indeed. Please note that not all functions in the libnix headers are implemented however. For example libnix has no real POSIX signal support at all.

Quote:
No. Also, when using ixemul you're not allowed to call the MorphOS native library functions directly. Everything has to go thru ixemul.library in this case, or you'll risk having execution interrupted in the middle of OS function (can lead to for example critical OS semaphore - I'm talking about struct SignalSemaphore here, not to be mixed with POSIX semaphores - being held while your app exits via signal handler).

If you want to call MorphOS functions then you need to use libnix (or you can skip standard libraries completely and manage everything manually, that is: -nostartfiles).

Quote:
MorphOS binaries are always position independent anyway, so there is no need for it.

[ Edited by Piru 10.04.2020 - 01:47 ]

Thanks a lot for the explanation and the link to libgnu, I almost forgot about that.

Quote:
Great! Any idea when the SDK will be out?
Quote:
Okay, but is then throwing an error a good solution? Wouldn't it be better to simply accept -pie?

Quote:

Piru simplified things a bit in his answer. -fPIC and -fPIE generate assembly code which is position independent in the sense that all pointers, jumps to address and so on are expressed in relative terms. In theory this could lead to some speed penalty (although I don't think it would be big on PPC). Anyhow, this type of position independent code is typically needed on *nix for e.g. shared libraries and for executables on embedded platforms. There is some problem in our linker related to GOT tables that currently prevents this from working properly at the moment. For the time being our GCC therefore issues a warning when trying to use these options.

It is on my todo list to fix this, but with low priority because as Piru mentioned, MorphOS executables are already position independent. Using a different method, they are relocated to another base than 0 at load time. To sum up, -fPIC and -fPIE do not make much sense on MorphOS.

Hope this clarifies.

@Nadir
Thanks a lot, now it is clear for me.

But I am still a bit puzzled regarding libnix/ixemul.

For example I want to port a small tool, which uses fts_close, fts_open, etc...
If I use ixemul, the thing just compiles and runs.
If I use libnix, linking fails because of missing fts_close, fts_open, etc...
What options do I have then? I guess I can try to implement the missing functions with "native" (dos, exec,...) functions?
How can I find out which functions are really implemented in libnix?

What about missing functions in case of ixemul? According to the docs I can't use any "native" functions/libs. So how can I implement missing functions? Just by using available POSIX functions of ixemul?

What about ported libs, like SDL? Can I use these with libnix, or ixemul, or both?

As a rule of thumb, if something is console-only, you use ixemul. If something opens a window, you must never use ixemul.

So for a console tool, especially if it interacts with bash scripts/makefiles, you use ixemul.
If you need compatibility with linux paths, you use ixemul.

If you need any sort of a windowed UI, you use libnix.

SDL ports must use libnix.