[openbeosstorage] Re: Getting rid of kernel_interface.POSIX.cpp
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: openbeosstorage@xxxxxxxxxxxxx
- Date: Wed, 04 Aug 2004 19:49:11 +0200 CEST
Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx> wrote:
> On 2004-06-29 at 22:30:19 [+0200], Axel Dörfler wrote:
> > I don't completely understand; for a start, we can simply copying
> > over
> > libstdc++.r4.so.
> Yes, we can copy it. The question is actually whether it works with
> our
> libroot. :-)
As Oliver found out, the libstdc++.r4 code is available at GeekGadgets,
too, so it looks like we've almost solved the issue (he is currently
trying to get it to run with our libio version...)
> > Also, we do have all the Be API in place, don't we?
> > Only functions that require an app_server connection won't work.
> > Which
> > is perfectly okay for now, I'd think, as we know which APIs are
> > affected and why.
> Currently the unit testing stuff uses BApplication. It may be that
> this is
> only for the BTestApp class though.
Can we solve this? Regression testing is not that senseless :)
OTOH there is no pressure, we could run the tests later, too (and fix
any issues then).
> > > I'd actually love, if you could wait a month, so that I could
> > > help
> > > with the transition. By then my job should go considerably
> > > easier,
> > > leaving me a reasonable amount of spare time again.
> > Sure, I can do that. I will just replace the BeOS syscalls with
> > Haiku
> > syscalls to make it link (and work) on our system (node watching).
> OK, cool.
There you go :)
I've changed libbeadapter.so to provide the new Haiku syscalls, and
changed all direct syscall uses to the new ones. The build system now
builds libbe.so as a stand-alone (and actually working) object.
> > What about special entry_ref support? Should there be functions
> > that
> > directly take an entry_ref, too?
> > I.e. something like:
> > _kern_open(int fd, entry_ref *ref, const char *path, ...)?
> > or
> > _kern_open(int fd, dev_t device, ino_t parent, const char *path,
> > ...)?
> >
> > But anyway, we can think about that later.
> Yep, it might be handy. When revising the classes implementation it
> will
> become much clearer, what actuallly makes sense. So let's way until
> then.
Okay.
> > Dunno; I think we can live without app_server for now. When the
> > issue
> > becomes more pressing, and the app_server team doesn't deliver, we
> > could ask them to make us a version that doesn't do graphics - I
> > would
> > think that this can't be that hard.
> > We may also be able to run parts of the Media Kit then :-)
> Yeah, the whole thing starts to really get exciting, doesn't it? :-)
Definitely!
> > I just have to squash out some serios bugs before...
> Yep, do that. :-)
Still need to :)
> > BTW libgcc.a is linked into libroot.so; and I need it to export all
> > functions that others could need. Marcus had the great idea to
> > dearchive libgcc.a and link the object files together into
> > libroot.so.
> > Do you have a quick idea on how a Jamrule achieving this could look
> > alike?
> I'm afraid there is no nice solution using jam. The problem is, that
> you
> need to feed the link rule with the names of the object files, which
> you
> don't have at that time. At least not in a generic way. I guess one
> has to
> list the object files explicitly. This would read like:
>
> LIBGCC_OBJECTS = foo.o bar.o ... ;
> LIBGCC_OBJECTS = $(LIBGCC_OBJECTS:G=libgcc) ;
> UnarchiveObjects $(LIBGCC_OBJECTS) : $(LIBGCC) ;
> ...
> Link libroot.so : ... $(LIBGCC_OBJECTS) ... ;
>
> The UnarchiveObjects rule should be straight forward, i.e. adding the
> dependencies, setting SEARCH and LOCATE...
I've done it this way, now - have a look if you like it :-)
Bye,
Axel.
Other related posts:
