Re: Getting rid of kernel_interface.POSIX.cpp

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

---559023410-758783491-1091794876=:14635
Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE

On Wed, 4 Aug 2004, Axel D=F6rfler wrote:

> Ingo Weinhold <bonefish-CFLBMwTPW48UNGrzBIF7/[email protected]> wrote:
>> On 2004-06-29 at 22:30:19 [+0200], Axel D=F6rfler 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...)

As I understood him last Tuesday, things are not so simple, but I'm=20
faithful nevertheless. :-)

>>> 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'll check, what is actually used where. I guess this can be solved even,=
=20
now (i.e. when we have a working STL), but as you say, the matter is not=20
that pressing.

>>>> 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.

OK, fine. I'll start as soon as I find the time. Not this weekend though,=
=20
since the weather is too nice and I'm going to do a little biking tour to=
=20
the Baltic Sea.

>>> 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 =3D foo.o bar.o ... ;
>> LIBGCC_OBJECTS =3D $(LIBGCC_OBJECTS:G=3Dlibgcc) ;
>> 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 :-)

Will do.

CU, Ingo
---559023410-758783491-1091794876=:14635--