Re: Linux port progress

Brian,
Glad to hear that you at least managed to get the VM compiled under
NetBSD. Can you send me a list of the changes you had to make to get
this working, so that I can look at incorporating them into gcc-linux
branch?

To run any of the scripts involves opening and reading the script file
which requires the libc library for file access. If you can't do this,
none of the scripts are going to make any difference, because you have
started executing any of their code.

Using libc.so was my first approach, however, under Ubuntu at least
this is a linker script file that dlopen cannot interpret properly. As
a first pass I chose instead to reference the shared object file
(actually the least specific link to it). If you have a simple
alternative suggestion, I'd be interested in hearing it.

Once you start putting library callouts as primitives where do you
stop? File access isn't really any different to any other external
call, other than as an initial hurdle to get scripted code running.

At the moment the mapping from generic library names to the shared
object files (and to DLLs under Windows) is quite simplistic.
Possibly, we could enhance the mapping code to do progressive lookups
for a number of possible shared object names. At the moment, there is
a single lookup. If that fails, it's an error and you're toast.

The possible incompatibilities in *nix environments is one reason I'm
not a fan of trying to support additional operating systems until we
have more people resources to do it. As to the offsets in the
StatBuffer structure one approach would be to offer different variants
of the class and use a factory method to access the class. If we moved
the platform class name from the os:: class to a property configurable
via the .strongtalkrc file we could avoid additional variants of the
os_*.cpp modules.

In the interim, in order to run the tests in your environment, how
about creating a link to the shared object file named libc.so.6?

Regards, Steve

On Dec 9, 6:48 am, Brian de Alwis <[email protected]> wrote:
> That's great news Stephen, and I'll look forward to those changes.
>
> I've managed to get the VM compiled and running on NetBSD with
> relatively few changes. With the image you provided on sendspace, the
> VM starts, the image loads and from tracing I can see ST code
> running.  So that's good news.
>
> If I start the VM with `-script test.dlt', I get a walkback from
> trying to resolve libc.so.6 -- UnixPlatform should probably just
> reference libc.so.  And the references to __fxstat in
> UnixFileDescriptor and the offsets in StatBuffer.  Perhaps the easiest
> solution in the long run is to push the file stuff as prims rather
> than loading from libc?
>
> I get the same results if I try running any other script.
> Unfortunately I only get the top 20 stack frames so I can't see where
> exactly this is coming from.  I've tried setting StackPrintLimit=40
> but to no avail.
>
> Brian.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Strongtalk-general" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [email protected]
For more options, visit this group at http://groups.google.com/group/strongtalk-general?hl=en
-~----------~----~----~----~------~----~------~--~---