Re: Linux port progress

Brian,
Actually, before you send me any code, you better to follow the
instructions on the Contributing page of the Wiki -
http://code.google.com/p/strongtalk/wiki/Contributing.

Regards, Steve

On Dec 9, 8:16 pm, talksmall <[email protected]> wrote:
> 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
-~----------~----~----~----~------~----~------~--~---