CogVM on FreeBSD

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

CogVM on FreeBSD

Holger Freyther
 
Good Morning,

I wonder what the state of the CogVM is on FreeBSD (9, 10)? The
FreeBSD port seems to build the plain squeakvm and not the CogVM?

kind regards
        holger
Reply | Threaded
Open this post in threaded view
|

Re: CogVM on FreeBSD

Frank Shearar-3
 
On 12 September 2014 11:02, Holger Hans Peter Freyther
<[hidden email]> wrote:
>
> Good Morning,
>
> I wonder what the state of the CogVM is on FreeBSD (9, 10)? The
> FreeBSD port seems to build the plain squeakvm and not the CogVM?

Cog doesn't run on FreeBSD at the moment, alas. Mainly because we lack
a FreeBSD expert who can tell us some bits around mcontexts and
ucontext_t things. If Eliot's OK with it, I can copy here the last
mail he sent me on the topic, when last he & I (mainly he!) took a run
at the problem.

frank

> kind regards
>         holger
Reply | Threaded
Open this post in threaded view
|

Re: CogVM on FreeBSD

David T. Lewis
In reply to this post by Holger Freyther
 
On Fri, Sep 12, 2014 at 12:02:55PM +0200, Holger Hans Peter Freyther wrote:
>  
> Good Morning,
>
> I wonder what the state of the CogVM is on FreeBSD (9, 10)? The
> FreeBSD port seems to build the plain squeakvm and not the CogVM?
>
> kind regards
> holger

<OT>

I don't know what is being distributed with FreeBSD, but if you have any
problems with it, note that the interpreter VM for FreeBSD is available
from squeakvm.org at http://www.squeakvm.org/unix/

</OT>

Dave

Reply | Threaded
Open this post in threaded view
|

Re: CogVM on FreeBSD

Holger Freyther
In reply to this post by Frank Shearar-3
 
On Fri, Sep 12, 2014 at 02:27:36PM +0100, Frank Shearar wrote:

Hi!

thank you for the quick info.

> Cog doesn't run on FreeBSD at the moment, alas. Mainly because we lack
> a FreeBSD expert who can tell us some bits around mcontexts and
> ucontext_t things. If Eliot's OK with it, I can copy here the last
> mail he sent me on the topic, when last he & I (mainly he!) took a run
> at the problem.

to me it looks like:

* fight bashism/gnuism.. or at least use "/usr/bin/env bash" instead
of hardcoding /bin/bash

* There seems to be quite some code that doesn't compile with clang.
(e.g. return from a function without value. this applies to plugins
with imported code and main Cog code)

* gcc/g++ doesn't exist but the usage is hardcoded in quite some
places. E.g. regenerating libtool could do wonder

* External libs/dependencies. When using COMPAT32 there is no libuuid
and I think I could do without the UUID Plugin.

* For  "backtrace" one needs to link -lexecinfo starting from FreeBSD
10.


What interests me more is how to get patches into the Cog branch? My
SCTP socket support and autoconf clean-ups never made it into the
branch.

cheers
        holger



Reply | Threaded
Open this post in threaded view
|

Re: CogVM on FreeBSD

Holger Freyther
 
On Fri, Sep 12, 2014 at 08:03:48PM +0200, Holger Hans Peter Freyther wrote:

Hi,


> What interests me more is how to get patches into the Cog branch? My
> SCTP socket support and autoconf clean-ups never made it into the
> branch.

attached are patches to modernize the usage of autoconf and remove
autogenerated configure files from the repository (it is an older
patch), the third patch is to use "mcontext_t" to fix the compilation
on FreeBSD.


src/plugins/VMProfileLinuxSupportPlugin/VMProfileLinuxSupportPlugin.c
needs to include dlfcn.h and should probably do the same on Linux.
Somebody would probably need to patch the code in the VMMaker and
including dlfcn.h on Linux should not hurt.

Somehow the linking of 'vm-display-null', 'vm-sound-null' do not work,
I end up with a .la and .a file but no 'vm-sound-null' binary. I had
to manually use the 'gcc -shared' line and link them.

Is there an easy way to see if some methods have been JITed?


kind regards
        holger



0001-These-files-are-generated-and-should-not-be-under-ve.patch.bz2 (199K) Download Attachment
0002-use-autoreconf-install-force-to-re-generate-the-buil.patch (13K) Download Attachment
0003-freebsd-Use-mcontext_t-on-FreeBSD-CURRENT-to-fix-the.patch (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: CogVM on FreeBSD

David T. Lewis
In reply to this post by Holger Freyther
 
On Fri, Sep 12, 2014 at 08:03:48PM +0200, Holger Hans Peter Freyther wrote:
>
> What interests me more is how to get patches into the Cog branch? My
> SCTP socket support and autoconf clean-ups never made it into the
> branch.
>

Holger,

I added an entry at http://bugs.squeak.org/view.php?id=7820 so we do not forget
about your SCTP changes.

Dave

Reply | Threaded
Open this post in threaded view
|

Re: CogVM on FreeBSD

Eliot Miranda-2

Hi Holger,


On Sep 27, 2014, at 5:27 PM, "David T. Lewis" <[hidden email]> wrote:

>
> On Fri, Sep 12, 2014 at 08:03:48PM +0200, Holger Hans Peter Freyther wrote:
>>
>> What interests me more is how to get patches into the Cog branch? My
>> SCTP socket support and autoconf clean-ups never made it into the
>> branch.

You submit them to me.  I'm sorry I didn't integrate these but they broke the build if one didnt have the relevant library installed.  So a little more work is needed so that the VM still builds on systems that don't have the SCTP code installed.  OK?


Eliot (phone)
>
> Holger,
>
> I added an entry at http://bugs.squeak.org/view.php?id=7820 so we do not forget
> about your SCTP changes.
>
> Dave
>
Reply | Threaded
Open this post in threaded view
|

Re: CogVM on FreeBSD

Holger Freyther
 
On Sun, Sep 28, 2014 at 12:34:32PM -0700, Eliot Miranda wrote:
>
> Hi Holger,

Hi Eliot,

> You submit them to me.  I'm sorry I didn't integrate these but they broke the build if one didnt have the relevant library installed.  So a little more work is needed so that the VM still builds on systems that don't have the SCTP code installed.  OK?

thank you for the reply. I think I have been there before and the
configure patches I sent was the result of that work. From my point
of view the dependency chain was like this. "I need to write a
configure.ac check" -> "I need to run autoreconf to generate a new
configure" -> "autoreconf fails" -> "I clean up autoconf".


kind regards
        holger