Problems compiling on NetBSD/m68k

Godmar Back gback at cs.utah.edu
Sun Feb 21 14:22:44 PST 1999


> 
> In article <199902212145.OAA07102 at sal.cs.utah.edu> you wrote:
> >The OSKit port of kaffe also provides its own implementation of libc.
> >While you're right that we don't want to keep your libc under CVS,
> >I think it's not a problem, you'd simply specify link lines in your
> >config.frag that would refer to your modified libc.
> >Kaffe Amiga users would still have to do two downloads and installations.
> 
> >As an aside, kaffe is not supposed to call any unsafe libc function.
> 
> Well, do you know which functions that are 'unsafe' ;)

No, I don't.  I assume that all functions that POSIX lists as 
async-signal-safe are safe.

If other functions are unsafe as well on some platforms, then we better 
include them in the syscall interface.  Who knows, maybe even sprintf may 
not be safe on some platforms.

> On Unix/POSIC systems where evertything is used using SYS_call and signal
> disabling it works fine, but in obscure ports of libc where you cannot rely
> in signal handling things works abit differently. Eg. gettimeofday is an
> unsafe call under AmigaOS since it calls into the os without doing a
> SYS_call. Also since i had to use my own signaling code to write the
> scheduler this makes things even trickier.
> 
> >They're either part of the jsyscall interface or calls to them must be 
> >protected via enter/leaveUnsafeRegion or a lock.
> 
> I also had to add my own startup code to do this since the standard crt0.o
> of course assumes that standard libc is used.

We had to substitute our own crt0 as well, we did this as part of the
gcc compiler driver.

Before we did this, we simply substituted our own link-rule in 
kaffe/kaffe/Makefile.in, but I'm not sure if automake allows to do that,
more importantly, I wouldn't know how to do it in automake.

> 
> The best approach would probably be to integrate the threading under 
> amiga-threads and have the libc patches available in a separate package.

You are of course free to do whatever you want, but personally I would
like to see kaffe structured in a way that changes like yours would indeed 
be localized in these two directories.

Maybe we're misunderstanding each other here.  My point of view is that
I don't want to rely on things that can break on some architectures.
Instead, I want to cleanly isolate those things.  For instance, if
gettimeofday is not safe (I believe it is in Posix), then let's add
it to the jsyscall interface and hide it in system/*/.

	- Godmar



More information about the kaffe mailing list