RE: Building on linux

I'm reviewing it currently.  It should be in within a few days.
-Dave

> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]]On Behalf Of
> [email protected]
> Sent: Tuesday, June 05, 2007 5:54 PM
> To: Strongtalk-general
> Subject: Re: Building on linux
>
>
>
> Has any of  prunedtree's work been merged onto the trunk yet?
>
> --
>
> On May 17, 5:33 am, prunedtree <[email protected]> wrote:
> > On May 15, 9:32 pm, talksmall <[email protected]> wrote:
> >
> >
> >
> >
> >
> > > On May 14, 8:14 pm, prunedtree <[email protected]> wrote:
> >
> > > > Regarding linux portage, I installed debian etch on a VM and started
> > > > to work with GCC 4.1
> > > > After some fixes (mainly wasting time to please GCC zeal) i got the
> > > > whole system (without os.cpp) to compile.
> >
> > > > All the link errors are related to os.cpp, which shows that the
> > > > current design is already very portable (one file contains all the
> > > > platform specificity)
> >
> > > > I'm now writing os_linux.cpp, the implementation of the
> needed linux-
> > > > specific code. Once i get the VM to compile under linux, I'll try to
> > > > pass a few benchmarks, but don't expect much because this is a very
> > > > unfriendly environnement to me, and i'm loosing way to much
> time. I'm
> > > > expecting linux users to keep the port alive after that.
> >
> > > > regards,
> > > > prunedtree
> >
> > > I've been lurking on the group for a while, and messing about for a
> > > little while with a linux port (Ubuntu Feisty Fawn, gcc 4.1.2, Eclipse
> > > CDT).
> >
> > > I've made some progress with the linux port. I've built a partial
> > > os.cpp (which I named gnu_os.cpp ... oh dear, nevermind). I have
> > > implemented the thread creation and os init portions and have stubbed
> > > out the rest for now, just to get it to link.
> >
> > > This is enough to resolve all of the os.cpp link dependencies. In
> > > addition I had to build a version of binutils with COFF support and
> > > rename a number of the symbols in order to link in the binaries.
> >
> > Does it work ? (well, it's not mandatory anymore anyway)
> >
> >
> >
> > > Unfortunately, I've had little luck with the noasm patches that you've
> > > posted to the group in the past :-( Any idea when these are to be
> > > merged into the mainline?
> >
> > > I have also had to make quite a few additions to the dependency files
> > > in order to resolve all of the include dependencies.
> >
> > Strange. My current tree compiles against both msvc 6 sp5 & gcc 3.4.4-
> > mingw32
> >
> >
> >
> > > My changes allow me to start the VM and singlestepping confirms that
> > > it's started executing the bytecode (resolving inline cache misses
> > > etc.). I soon get a seg fault though which I'm trying to track down.
> >
> > When i ported to GCC i had to fix several nasty bugs before getting
> > everything to run. GCC misses some an empty base class optimisation
> > and displaces the primary/secondary caches... this crashes the
> > interpreter when they are accessed in assembly. Other bug is related
> > to a __GNUC__ flag disabling the special calling convention for
> > primitives (but the assembly code doesn't pop the stack, so you need
> > pascal convention). Might be other GCC issues i fixed, moreover I did
> > a few changes that improve stability (guarding against edx trashing in
> > constant propagation of primitives in the compiler for instance)
> >
> >
> >
> > > The changes I have made so far are enough to indicate that the OS
> > > dependencies leak out a little further than os.cpp. thread ids are
> > > referenced as ints (on linux they are pthread_t s - POSIX threads
> > > don't you know) Event and Thread are downcasts of Windows HANDLEs and
> > > the handles themselves are exposed via get_hinstance etc. I've
> > > implemented a wrapper Thread class and an Event wrapping a semaphore
> > > protected boolean to take care of some of this and just ignored the
> > > handles for now.
> >
> > Interressing. There is indeed some win32-specific things (the stuff
> > related to hinstance, etc...) But it looks like we only need some
> > cleanup to achieve a fairly neutral API. This part of the VM is not
> > performance-critical, so we can afford encapsulation overhead.
> >
> > > Done nothing with DLLs or the timing functions.
> > > Possible problem there - Linux only seems to have support for per
> > > process timing stats. May not be an issue as the current VM is
> > > effectively almost single threaded - handing off from one thread to
> > > another via transfer_to etc.
> >
> > > Happy to share my changes so far. Even happier if we can reconcile
> > > them with your noasm changes :-)
> >
> > I'm happy to see someone is up to the task. As you probably noticed,
> > i'm not very motivated to do this port, other than helping linux folks
> > getting it done. To cooperate it would be much easier if you could
> > contact me on IRC. i'm on #squeak (on freenode) and #smalltalk (on
> > dalnet) as "prunedtree".
> >
> > If you can't reach me on IRC, send me a mail.
> >
> > regards,
> > prunedtree
> >
> >
> >
> >
> >
> > > Cheers,
> > > talksmall- Hide quoted text -
> >
> > - Show quoted text -- Hide quoted text -
> >
> > - Show quoted text -
>
>
> >


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