Re: Building on linux

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.

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.

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.

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

Cheers,
talksmall



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