Problems compiling on NetBSD/m68k
gback at cs.utah.edu
Sun Feb 21 13:45:40 PST 1999
> In article <199902211940.MAA05900 at sal.cs.utah.edu> you wrote:
> >> Another problem with my Amiga port of kaffe is that I have had to create a
> >> completely custom libc to make sure that everything is threadsafe. Since
> >> AmigaOS doesn't do file io via descriptors in a unix way I had to write my
> >> own code to make sure that they are not blocking. But I guess that you
> >> don't want to include this in the main kaffe tree ;)
> >Sure, why not?
> Because it is basically 200k tree with all the libc functions.
> >>From your description, I assume that the changes are or can be localized
> >to system/amiga-threads and config/m68k/amiga. Is that not true?
> >I don't see any reason why we wouldn't include them.
> Well, I guess so, it would just become and extra 200k bagage to kaffe which
> some people may not want. I could of course strip out all the 'safe'
> functions, but the way things are implemented right now is that libc is
> completely avoided to make sure that no one accidently pulls a dangerous
> function from libc. On my end it would generate a linkage error and I'd
> simply add that function to my safelibc.
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.
They're either part of the jsyscall interface or calls to them must be
protected via enter/leaveUnsafeRegion or a lock.
More information about the kaffe