No vm-display-x11 Plug-in After Building From Source On FreeBSD 10.1

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
37 messages Options
12
B J
Reply | Threaded
Open this post in threaded view
|

No vm-display-x11 Plug-in After Building From Source On FreeBSD 10.1

B J
Instead of using:

pkg install squeak

or building it from ports on FreeBSD 10.1, I tried building it from
source.  It can't find vm-display-x11.so because it doesn't exist.

I went through the usual "config" and "make" procedures, so I'm
wondering what might have happened.

As before, I've got the i386 version of FreeBSD 10.1 installed with
the Mate desktop and Slim login manager.

Does anyone have any ideas?  Thanks.

Reply | Threaded
Open this post in threaded view
|

Re: No vm-display-x11 Plug-in After Building From Source On FreeBSD 10.1

Bert Freudenberg
On 14.12.2014, at 05:23, B J <[hidden email]> wrote:

>
> Instead of using:
>
> pkg install squeak
>
> or building it from ports on FreeBSD 10.1, I tried building it from
> source.  It can't find vm-display-x11.so because it doesn't exist.
>
> I went through the usual "config" and "make" procedures, so I'm
> wondering what might have happened.
>
> As before, I've got the i386 version of FreeBSD 10.1 installed with
> the Mate desktop and Slim login manager.
>
> Does anyone have any ideas?  Thanks.
There's a couple things that may go wrong:

It's possible it was not built because of missing header or library files.

It's also possible the module's file name is different (e.g. on Linux it is so.vm-display-x11) so you might have a look in the vm's lib directory for what the actual name is.

Also, if you did not run "make install" you will have to pass the actual directory name for the plugins on the vm's command line.

Finally, even if the VM finds the module, it may fail to load if some dependent library is missing. On Linux I can check with "ldd pluginfile", not sure what the equivalent BSD command is.

- Bert -






smime.p7s (5K) Download Attachment
tty
Reply | Threaded
Open this post in threaded view
|

Re: No vm-display-x11 Plug-in After Building From Source On    FreeBSD 10.1

tty
In reply to this post by B J
---- On Sat, 13 Dec 2014 20:23:02 -0800 B J<[hidden email]> wrote ----
Instead of using:

pkg install squeak

or building it from ports on FreeBSD 10.1, I tried building it from
source. It can't find vm-display-x11.so because it doesn't exist.

When I have had this problem on Linux, the export LD_LIBRARY_PATH has worked for me.

(looks for launch scripts...somewhere around here....ah..)


#!/bin/bash
export LD_LIBRARY_PATH=/home/tty/usr/bin/coglinux
/home/tty/usr/bin/coglinux/squeak -vm-sound-ALSA -vm-display-X11 -xshm Contents/Resources/images/MostInteresting.image 

The tree of that LD_LIBRARY_PATH looks like this:



 bash-4.2$ tree /home/wm/usr/bin/coglinux
/home/wm/usr/bin/coglinux
|-- bin
| `-- squeak
|-- doc
| `-- squeak
| |-- COPYING.gz
| |-- COPYRIGHT.gz
| |-- LICENSE.gz
| |-- README.Contributing.gz
| |-- README.Keyboard.gz
| `-- README.Sound.gz
|-- lib
| `-- squeak
| `-- 4.0-3126
| |-- B3DAcceleratorPlugin
| |-- BochsIA32Plugin
| |-- LocalePlugin
| |-- SqueakFFIPrims
| |-- SqueakSSL
| |-- UUIDPlugin
| |-- UnicodePlugin
| |-- UnixOSProcessPlugin
| |-- XDisplayControlPlugin
| |-- squeak
| |-- vm-display-X11
| |-- vm-display-fbdev
| |-- vm-display-null
| |-- vm-sound-ALSA
| |-- vm-sound-OSS
| |-- vm-sound-null
| `-- vm-sound-pulse
|-- man
| `-- man1
| `-- squeak.1
`-- squeak

hth.

tty






B J
Reply | Threaded
Open this post in threaded view
|

Re: No vm-display-x11 Plug-in After Building From Source On FreeBSD 10.1

B J
In reply to this post by Bert Freudenberg
<snip>

Thanks.

> There's a couple things that may go wrong:
>
> It's possible it was not built because of missing header or library files.
>
> It's also possible the module's file name is different (e.g. on Linux it is
> so.vm-display-x11)

I've noticed that with FreeBSD when I tried installing Squeak from the
repository.

so you might have a look in the vm's lib directory for
> what the actual name is.

It said it was looking for vm-display-x11.so, but if so.vm-display-x11
is what's produced, I'm assuming that an error would result.

>
> Also, if you did not run "make install" you will have to pass the actual
> directory name for the plugins on the vm's command line.

The instructions suggest running "make" first, checking out the
results first, and then running "make install".  I didn't go further
than just "make" because of the error.

>
> Finally, even if the VM finds the module, it may fail to load if some
> dependent library is missing. On Linux I can check with "ldd pluginfile",
> not sure what the equivalent BSD command is.

I haven't tried that yet.

B J
Reply | Threaded
Open this post in threaded view
|

Re: No vm-display-x11 Plug-in After Building From Source On FreeBSD 10.1

B J
In reply to this post by tty
<snip>

> When I have had this problem on Linux, the export LD_LIBRARY_PATH has worked
> for me.
>
>
>
> (looks for launch scripts...somewhere around here....ah..)
>
>
>
>
> #!/bin/bash
> export LD_LIBRARY_PATH=/home/tty/usr/bin/coglinux
> /home/tty/usr/bin/coglinux/squeak -vm-sound-ALSA -vm-display-X11 -xshm
> Contents/Resources/images/MostInteresting.image

The error message mentioned something about that as well.  I didn't
find any information on how to handle it.  This might be what I was
looking for.

>
>
>
>
> The tree of that LD_LIBRARY_PATH looks like this:
>
>
>
>
>
>
>  bash-4.2$ tree /home/wm/usr/bin/coglinux
> /home/wm/usr/bin/coglinux
> |-- bin
> | `-- squeak
> |-- doc
> | `-- squeak
> | |-- COPYING.gz
> | |-- COPYRIGHT.gz
> | |-- LICENSE.gz
> | |-- README.Contributing.gz
> | |-- README.Keyboard.gz
> | `-- README.Sound.gz
> |-- lib
> | `-- squeak
> | `-- 4.0-3126
> | |-- B3DAcceleratorPlugin
> | |-- BochsIA32Plugin
> | |-- LocalePlugin
> | |-- SqueakFFIPrims
> | |-- SqueakSSL
> | |-- UUIDPlugin
> | |-- UnicodePlugin
> | |-- UnixOSProcessPlugin
> | |-- XDisplayControlPlugin
> | |-- squeak
> | |-- vm-display-X11
> | |-- vm-display-fbdev
> | |-- vm-display-null
> | |-- vm-sound-ALSA
> | |-- vm-sound-OSS
> | |-- vm-sound-null
> | `-- vm-sound-pulse
> |-- man
> | `-- man1
> | `-- squeak.1
> `-- squeak
>
> hth.

I think it might.  However, I've written and debugged enough code over
the years to know that fixing one bug will likely generate lots more
and if it runs right the first time, I did something wrong.  :-)

<snip>

Reply | Threaded
Open this post in threaded view
|

Re: No vm-display-x11 Plug-in After Building From Source On FreeBSD 10.1

David T. Lewis
In reply to this post by B J
On Sun, Dec 14, 2014 at 03:02:32PM +0000, B J wrote:

> <snip>
>
> Thanks.
>
> > There's a couple things that may go wrong:
> >
> > It's possible it was not built because of missing header or library files.
> >
> > It's also possible the module's file name is different (e.g. on Linux it is
> > so.vm-display-x11)
>
> I've noticed that with FreeBSD when I tried installing Squeak from the
> repository.
>
> so you might have a look in the vm's lib directory for
> > what the actual name is.
>
> It said it was looking for vm-display-x11.so, but if so.vm-display-x11
> is what's produced, I'm assuming that an error would result.
>
> >
> > Also, if you did not run "make install" you will have to pass the actual
> > directory name for the plugins on the vm's command line.
>
> The instructions suggest running "make" first, checking out the
> results first, and then running "make install".  I didn't go further
> than just "make" because of the error.
>
> >
> > Finally, even if the VM finds the module, it may fail to load if some
> > dependent library is missing. On Linux I can check with "ldd pluginfile",
> > not sure what the equivalent BSD command is.
>
> I haven't tried that yet.
If you think that the module is not being built at all, take a look at the config.h
file in your build directory. That is the output of the cmake configure process,
and if there is some issue related to locating the build libraries, you will probably
see evidence of it in config.h. Look for definitions that are commented out, but
maybe should not be.

Note, the "so.xxxx" naming convention is part of the installation process, so
don't worry about that. If you can build the VM and install it, the naming will
take care of itself.

I'm not sure which source package you are starting with, but here is a simple
recipe for building the latest from Subversion.

1) Start with an empty directory, then get the latest versions of all the
platforms sources and the VMMaker generated sources:

  $ svn co http://squeakvm.org/svn/squeak/trunk/platforms
  $ svn co http://squeakvm.org/svn/squeak/trunk/src

2) In that same directory, make a subdirectory in which to build the VM:

  $ mkdir build
  $ cd build

3) Copy the attached Makefile into your build directory.

4) build the VM, and install it if you get plausible results.

  $ make
  $ sudo make install

This makefile is what I use on Linux, so you may need to fiddle around with the
CFLAGS, or add additional "--without xxxx" options to exclude modules that give
you problems, but otherwise I think it should work.

HTH,
Dave




Makefile (1K) Download Attachment
B J
Reply | Threaded
Open this post in threaded view
|

Re: No vm-display-x11 Plug-in After Building From Source On FreeBSD 10.1

B J
Thanks for the info.

> If you think that the module is not being built at all, take a look at the
> config.h
> file in your build directory. That is the output of the cmake configure
> process,
> and if there is some issue related to locating the build libraries, you will
> probably
> see evidence of it in config.h. Look for definitions that are commented out,
> but
> maybe should not be.
>
> Note, the "so.xxxx" naming convention is part of the installation process,
> so
> don't worry about that. If you can build the VM and install it, the naming
> will
> take care of itself.
>
> I'm not sure which source package you are starting with, but here is a
> simple
> recipe for building the latest from Subversion.

I was using the compressed file on:

http://squeakvm.org/unix/index.html

>
> 1) Start with an empty directory, then get the latest versions of all the
> platforms sources and the VMMaker generated sources:
>
>   $ svn co http://squeakvm.org/svn/squeak/trunk/platforms
>   $ svn co http://squeakvm.org/svn/squeak/trunk/src
>
> 2) In that same directory, make a subdirectory in which to build the VM:
>
>   $ mkdir build
>   $ cd build
>
> 3) Copy the attached Makefile into your build directory.
>
> 4) build the VM, and install it if you get plausible results.
>
>   $ make
>   $ sudo make install
>
> This makefile is what I use on Linux, so you may need to fiddle around with
> the
> CFLAGS, or add additional "--without xxxx" options to exclude modules that
> give
> you problems, but otherwise I think it should work.

I think this might help.  I'll see what happens with this.

<snip>

tty
Reply | Threaded
Open this post in threaded view
|

Re: Re: [squeak-dev] No vm-display-x11 Plug-in After Building From Source On FreeBSD 10.1

tty
David, BJ

If this does work, we can take the CMakeLists.txt files and other cmake files and port them directly to the CMakeVMMakerSqueak BSD configuration so that we
have a repository of this work.  

In CMakeVMMakerSqueak--it is CMake that drives the process, and Smalltalk just encapsulates what works.

I expect to have a first release tomorrow (was going to be today, but it turned out to be a warm, beautiful day and I got distracted (: )


cheers,

tty.


---- On Sun, 14 Dec 2014 12:16:40 -0800 B J <[hidden email]> wrote ----
Thanks for the info.

> If you think that the module is not being built at all, take a look at the
> config.h
> file in your build directory. That is the output of the cmake configure
> process,
> and if there is some issue related to locating the build libraries, you will
> probably
> see evidence of it in config.h. Look for definitions that are commented out,
> but
> maybe should not be.
>
> Note, the "so.xxxx" naming convention is part of the installation process,
> so
> don't worry about that. If you can build the VM and install it, the naming
> will
> take care of itself.
>
> I'm not sure which source package you are starting with, but here is a
> simple
> recipe for building the latest from Subversion.

I was using the compressed file on:

http://squeakvm.org/unix/index.html

>
> 1) Start with an empty directory, then get the latest versions of all the
> platforms sources and the VMMaker generated sources:
>
> $ svn co http://squeakvm.org/svn/squeak/trunk/platforms
> $ svn co http://squeakvm.org/svn/squeak/trunk/src
>
> 2) In that same directory, make a subdirectory in which to build the VM:
>
> $ mkdir build
> $ cd build
>
> 3) Copy the attached Makefile into your build directory.
>
> 4) build the VM, and install it if you get plausible results.
>
> $ make
> $ sudo make install
>
> This makefile is what I use on Linux, so you may need to fiddle around with
> the
> CFLAGS, or add additional "--without xxxx" options to exclude modules that
> give
> you problems, but otherwise I think it should work.

I think this might help. I'll see what happens with this.

<snip>





B J
Reply | Threaded
Open this post in threaded view
|

Re: Re: [squeak-dev] No vm-display-x11 Plug-in After Building From Source On FreeBSD 10.1

B J
On 12/14/14, gettimothy <[hidden email]> wrote:

> David, BJ
>
>
>
> If this does work, we can take the CMakeLists.txt files and other cmake
> files and port them directly to the CMakeVMMakerSqueak BSD configuration so
> that we
> have a repository of this work.
>
>
> In CMakeVMMakerSqueak--it is CMake that drives the process, and Smalltalk
> just encapsulates what works.
>
>
> I expect to have a first release tomorrow (was going to be today, but it
> turned out to be a warm, beautiful day and I got distracted (: )

I'll try it later today.

<snip>

Reply | Threaded
Open this post in threaded view
|

Re: No vm-display-x11 Plug-in After Building From Source On FreeBSD 10.1

timrowledge
In reply to this post by David T. Lewis
Had the same - probably - issue a few weeks ago building under Raspbian.

So far as I could work out the problem is to do with the location of GL library and headers. In Raspbian I was loading the mesa-common-dev in order to get the openGL stuff. Without it you can build a working VM but without the B3DAcceleratorPlugin. With it the config ‘passes’ the test for the presence of the GH.h header(s) but the resultant vm-display-X11.so isn’t correctly linked to the libGL and so won’t come up.

You *can* force a preload to get around this. For example
`LD_PRELOAD=/usr/lib/arm-linux-gnueabihf/libGL.so.1`
stuck in front of the
exec “$Bin/squeak…..
stuff seemed to solve the problem pro tem.

Take a look at your squeak.stack.v3/build/config.log (or close equivalent) to see if this is the problem. Search for something like
`checking GL/gl.h usability`
and look at the output after that.
If it doesn’t report
`fatal error: GL/gl.h: No such file or directory`
then see if any of the compile/link stuff after that is trying to use -lGL as in libGL. My guess is that you have GL.h but the path to libGL is not correct. I don’t know how to fix that. My best answer was to remove the mesa-common-dev package and sidestep it for now.

AutoBlech and it’s kin are crimes against nature.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Never forget: 2 + 2 = 5 for extremely large values of 2.



Reply | Threaded
Open this post in threaded view
|

Re: No vm-display-x11 Plug-in After Building From Source On FreeBSD 10.1

David T. Lewis
On Sun, Dec 14, 2014 at 06:01:17PM -0800, tim Rowledge wrote:

> Had the same - probably - issue a few weeks ago building under Raspbian.
>
> So far as I could work out the problem is to do with the location of GL library and headers. In Raspbian I was loading the mesa-common-dev in order to get the openGL stuff. Without it you can build a working VM but without the B3DAcceleratorPlugin. With it the config ?passes? the test for the presence of the GH.h header(s) but the resultant vm-display-X11.so isn?t correctly linked to the libGL and so won?t come up.
>
> You *can* force a preload to get around this. For example
> `LD_PRELOAD=/usr/lib/arm-linux-gnueabihf/libGL.so.1`
> stuck in front of the
> exec ?$Bin/squeak?..
> stuff seemed to solve the problem pro tem.
>
> Take a look at your squeak.stack.v3/build/config.log (or close equivalent) to see if this is the problem. Search for something like
> `checking GL/gl.h usability`
> and look at the output after that.
> If it doesn?t report
> `fatal error: GL/gl.h: No such file or directory`
> then see if any of the compile/link stuff after that is trying to use -lGL as in libGL. My guess is that you have GL.h but the path to libGL is not correct. I don?t know how to fix that. My best answer was to remove the mesa-common-dev package and sidestep it for now.
>
> AutoBlech and it?s kin are crimes against nature.
>
> tim

Ian Piumarta ditched his earlier "autoblech" build and replaced it
with a much better CMake process. I think this was about a half dozen
years ago (!).  Presumably he did that in part because of the problems
that you are now experiencing. I also recall that there were some real
issues with 32 and 64 bit library management that were intractable
with autotools at the time, and that the CMake folks seem to have
addressed reasonably well.

Personally, I have very little patience for any of this stuff, so
I am happy to make use of the CMake build that Ian provided. It works
well, and has not had any of the 32/64 bit library management problems
that autotools were encountering at that time. It also works on my new
Ubuntu laptop with who knows what sort of compiler and build tools
(more than I can say for the autotools builds).

It is a complete mystery to me why anyone would want to reinvent this
particular wheel.

Dave

tty
Reply | Threaded
Open this post in threaded view
|

Re: Re: [squeak-dev] No vm-display-x11 Plug-in After Building From Source On FreeBSD 10.1

tty
Hi David,

CMakeVMMakerSqueak wraps Ian's  CMake code

Ian Piumarta ditched his earlier "autoblech" build and replaced it
with a much better CMake process. I think this was about a half dozen
years ago (!). Presumably he did that in part because of the problems
that you are now experiencing. I also recall that there were some real
issues with 32 and 64 bit library management that were intractable
with autotools at the time, and that the CMake folks seem to have
addressed reasonably well.

Personally, I have very little patience for any of this stuff, so
I am happy to make use of the CMake build that Ian provided. It works
well, and has not had any of the 32/64 bit library management problems
that autotools were encountering at that time. It also works on my new
Ubuntu laptop with who knows what sort of compiler and build tools
(more than I can say for the autotools builds).

It is a complete mystery to me why anyone would want to reinvent this
particular wheel.


(with some small differences in plugin-approach that can be standardized via refactoring if needed).

I have differed with Pharo team in that CMAKE DRIVES THE PROCESS. We start with a working CMake and just encapsulate that in Squeak.

Ian's CMake code lives in CMakeVMMakerSqueak in the same way that the VM codebase lives in Squeak.


I look forward to discussing once I get the (minimal) beta-release for linux32 out today (which should be readily portable to Tim Rowledge's ARM platform and BJ's BSD platform and the gentleman who wants a SunOS port) .

Here is the short version of the project.

Stage 1. get Pharo code working on squeak--this worked fine and was easy.
Stage 2. Support Eliot's needs for number of platforms, languages, vm's and build types. I attempted to bolt this on with possibly the most ridiculous use of a Trait ever attempted in world history. That approach was abandoned when I discovered that a massive Trait is not loadable via monticello unless one has several decades available for download time.

Stage 3. was Study Ian's code and CMake--(light bulbs go light up in tty's brain).
Stage 4 was attempt to do both Pharo and Squeak and Ian's CMake with existing framework.
Stage 5. Abandon attempt to shoe-horn Ian's CMake into Pharo.
Stage 6. Implement CMake Template approach which are small classes that wrap CMake constructs and that output their contents to a stream (think Seaside Components)
Stage 7. Compare 6 output to Ian's code. They are pretty much tit-for-tat.

This tool just generates CMake. If there are problems with configuration and compilation, they are addressed by modifying the generated CMake. The resulting edits can then be incoorporated into an existing CMakeVMMakerSqueak Configuration or ported to a new configuration.

To use this tool, ONE MUST THINK IN CMAKE, which is what Ian did, which is how this project will progress.

Did I mention the tool is CMake driven ?

(:

cordially,

tty











Reply | Threaded
Open this post in threaded view
|

Re: Re: [squeak-dev] No vm-display-x11 Plug-in After Building From Source On FreeBSD 10.1

David T. Lewis
Hi tty,

Sounds good :-)

Dave

> Hi David,
>
> CMakeVMMakerSqueak wraps Ian's  CMake code
>
> Ian Piumarta ditched his earlier "autoblech" build and replaced it
> with a much better CMake process. I think this was about a half dozen
> years ago (!). Presumably he did that in part because of the problems
> that you are now experiencing. I also recall that there were some real
> issues with 32 and 64 bit library management that were intractable
> with autotools at the time, and that the CMake folks seem to have
> addressed reasonably well.
>
> Personally, I have very little patience for any of this stuff, so
> I am happy to make use of the CMake build that Ian provided. It works
> well, and has not had any of the 32/64 bit library management problems
> that autotools were encountering at that time. It also works on my new
> Ubuntu laptop with who knows what sort of compiler and build tools
> (more than I can say for the autotools builds).
>
> It is a complete mystery to me why anyone would want to reinvent this
> particular wheel.
>
>
>
> (with some small differences in plugin-approach that can be standardized
> via refactoring if needed).
>
> I have differed with Pharo team in that CMAKE DRIVES THE PROCESS. We start
> with a working CMake and just encapsulate that in Squeak.
>
> Ian's CMake code lives in CMakeVMMakerSqueak in the same way that the VM
> codebase lives in Squeak.
>
>
> I look forward to discussing once I get the (minimal) beta-release for
> linux32 out today (which should be readily portable to Tim Rowledge's ARM
> platform and BJ's BSD platform and the gentleman who wants a SunOS port) .
>
> Here is the short version of the project.
>
> Stage 1. get Pharo code working on squeak--this worked fine and was easy.
> Stage 2. Support Eliot's needs for number of platforms, languages, vm's
> and build types. I attempted to bolt this on with possibly the most
> ridiculous use of a Trait ever attempted in world history. That approach
> was abandoned when I discovered that a massive Trait is not loadable via
> monticello unless one has several decades available for download time.
>
> Stage 3. was Study Ian's code and CMake--(light bulbs go light up in tty's
> brain).
> Stage 4 was attempt to do both Pharo and Squeak and Ian's CMake with
> existing framework.
> Stage 5. Abandon attempt to shoe-horn Ian's CMake into Pharo.
> Stage 6. Implement CMake Template approach which are small classes that
> wrap CMake constructs and that output their contents to a stream (think
> Seaside Components)
> Stage 7. Compare 6 output to Ian's code. They are pretty much tit-for-tat.
>
> This tool just generates CMake. If there are problems with configuration
> and compilation, they are addressed by modifying the generated CMake. The
> resulting edits can then be incoorporated into an existing
> CMakeVMMakerSqueak Configuration or ported to a new configuration.
>
> To use this tool, ONE MUST THINK IN CMAKE, which is what Ian did, which is
> how this project will progress.
>
> Did I mention the tool is CMake driven ?
>
> (:
>
> cordially,
>
> tty
>
>
>
>
>
>
>
>
>
>
>
>
>
>



Reply | Threaded
Open this post in threaded view
|

Re: No vm-display-x11 Plug-in After Building From Source On FreeBSD 10.1

timrowledge
In reply to this post by David T. Lewis

On 14-12-2014, at 7:35 PM, David T. Lewis <[hidden email]> wrote:
>
> Ian Piumarta ditched his earlier "autoblech" build and replaced it
> with a much better CMake process. I think this was about a half dozen
> years ago (!).  

I think it was a little after Cog was split off, which explains the dual insanity we have now. I really hope tty is getting close to producing a working CMake setup we can accept to replace the autoblech for Cog. When I offered the bounty for doing this (a year ago!) I imagined that somebody with some relevant experience would simply copy across the plain interp related CMake files and extend them, maybe add a few more bits for the extra files Cog brings in, sprinkle some fairy dust and *foom*! done.

But in the end I don’t care how it’s done, just that it *is* done.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
this blank intentionally left spaced



B J
Reply | Threaded
Open this post in threaded view
|

Re: No vm-display-x11 Plug-in After Building From Source On FreeBSD 10.1

B J
In reply to this post by David T. Lewis
<snip>

> If you think that the module is not being built at all, take a look at the
> config.h
> file in your build directory. That is the output of the cmake configure
> process,
> and if there is some issue related to locating the build libraries, you will
> probably
> see evidence of it in config.h. Look for definitions that are commented out,
> but
> maybe should not be.

Nothing that I might recognize stood out for me.

>
> Note, the "so.xxxx" naming convention is part of the installation process,
> so
> don't worry about that. If you can build the VM and install it, the naming
> will
> take care of itself.
>
> I'm not sure which source package you are starting with, but here is a
> simple
> recipe for building the latest from Subversion.
>
> 1) Start with an empty directory, then get the latest versions of all the
> platforms sources and the VMMaker generated sources:
>
>   $ svn co http://squeakvm.org/svn/squeak/trunk/platforms
>   $ svn co http://squeakvm.org/svn/squeak/trunk/src
>
> 2) In that same directory, make a subdirectory in which to build the VM:
>
>   $ mkdir build
>   $ cd build
>
> 3) Copy the attached Makefile into your build directory.

It wanted to install a 64-bit version.  I haven't attempted to edit to
file for 32 bits.

>
> 4) build the VM, and install it if you get plausible results.
>
>   $ make
>   $ sudo make install

I used:

/root/Desktopo/squeak/platorms/unix/cmake/configure

followed by:

make
make install

I got the same results as before, though there was a squeakvm.core
file in my build directory as a result of the crash.

There is a vm-display-X11 directory in my build directory, but when I
open it, there's a directory named "CMakeFiles".  Inside that, is
"vm-display-X11.dir" and, going further, it looks like its a
continuing series of nested directories.


>
> This makefile is what I use on Linux, so you may need to fiddle around with
> the
> CFLAGS, or add additional "--without xxxx" options to exclude modules that
> give
> you problems, but otherwise I think it should work.

I haven't tried that yet, partly because I don't know enough about
what's going on.

The mystery continues.

<snip>

Reply | Threaded
Open this post in threaded view
|

Re: No vm-display-x11 Plug-in After Building From Source On FreeBSD 10.1

David T. Lewis
Hi,

The only other thing I can thing of right now is to check and make sure that you
are running the VM that you built, and not by accident running some left over
bits of the last installation. In particular, a package that you installed from
the FreeBSD distribution might have installed a /usr/bin/squeak script, whereas
the local build would have installed in /usr/local/bin/squeak.

So double check that you are running /usr/local/bin/squeak and not /usr/bin/squeak.
On my box it looks like this:

$ type squeak
squeak is hashed (/usr/local/bin/squeak)

$ squeak -version
4.13.8-3183 #1 XShm Sun Dec 14 12:04:38 EST 2014 /usr/bin/cc
Linux LexIT-Gazelle-Professional 3.11.0-26-generic #45-Ubuntu SMP Tue Jul 15 04:02:06 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
plugin path: /usr/local/lib/squeak/4.13.8-3183 [default: /usr/local/lib/squeak/4.13.8-3183/]

A few other thoughts in line below.

Dave


On Tue, Dec 16, 2014 at 05:15:57AM +0000, B J wrote:

> <snip>
>
> > If you think that the module is not being built at all, take a look at the
> > config.h
> > file in your build directory. That is the output of the cmake configure
> > process,
> > and if there is some issue related to locating the build libraries, you will
> > probably
> > see evidence of it in config.h. Look for definitions that are commented out,
> > but
> > maybe should not be.
>
> Nothing that I might recognize stood out for me.
>

OK, so the display module is being built, and after "make install" you would
find it installed as /usr/local/lib/squeak/4.13.8-3183/so.vm-display-X11

> >
> > Note, the "so.xxxx" naming convention is part of the installation process,
> > so
> > don't worry about that. If you can build the VM and install it, the naming
> > will
> > take care of itself.
> >
> > I'm not sure which source package you are starting with, but here is a
> > simple
> > recipe for building the latest from Subversion.
> >
> > 1) Start with an empty directory, then get the latest versions of all the
> > platforms sources and the VMMaker generated sources:
> >
> >   $ svn co http://squeakvm.org/svn/squeak/trunk/platforms
> >   $ svn co http://squeakvm.org/svn/squeak/trunk/src
> >
> > 2) In that same directory, make a subdirectory in which to build the VM:
> >
> >   $ mkdir build
> >   $ cd build
> >
> > 3) Copy the attached Makefile into your build directory.
>
> It wanted to install a 64-bit version.  I haven't attempted to edit to
> file for 32 bits.
>

The 64-bit version should be fine (I use the 64-bit VM regularly and no longer
bother building a 32-bit version for my own use). It's possible that your image
is making use of some plugin that still has 64-bit issues, but I think this is
not likely.

If you want to build in 32-bit mode, add "-m32" to the CFLAGS in the Makefile,
then "make clean; make; sudo make install".


> >
> > 4) build the VM, and install it if you get plausible results.
> >
> >   $ make
> >   $ sudo make install
>
> I used:
>
> /root/Desktopo/squeak/platorms/unix/cmake/configure
>
> followed by:
>
> make
> make install
>
> I got the same results as before, though there was a squeakvm.core
> file in my build directory as a result of the crash.
>
> There is a vm-display-X11 directory in my build directory, but when I
> open it, there's a directory named "CMakeFiles".  Inside that, is
> "vm-display-X11.dir" and, going further, it looks like its a
> continuing series of nested directories.

That is normal CMake build stuff. The so.vm-display-X11 file that is installed
after "make install" is the only one that matters, and it should be activated
when you run the VM normally (/usr/local/bin/squeak myimage).

>
>
> >
> > This makefile is what I use on Linux, so you may need to fiddle around with
> > the
> > CFLAGS, or add additional "--without xxxx" options to exclude modules that
> > give
> > you problems, but otherwise I think it should work.
>
> I haven't tried that yet, partly because I don't know enough about
> what's going on.

I guess one more thing that would be worth trying is to turn off compiler
optimization. There are a lot of versions of gcc floating around and they
are not all equally reliable. Try setting optimation level to zero like
this in the Makefile that I sent (that's a zero in the "-O0"):

CFLAGS_PARAM="--CFLAGS='-O0 -D_FILE_OFFSET_BITS=64'"

>
> The mystery continues.
>
> <snip>

tty
Reply | Threaded
Open this post in threaded view
|

Re: Re: [squeak-dev] No vm-display-x11 Plug-in After Building From Source On FreeBSD 10.1

tty
In reply to this post by timrowledge
Hi Tim.


think it was a little after Cog was split off, which explains the dual insanity we have now. I really hope tty is getting close to producing a working CMake setup we can accept to replace the autoblech for Cog. When I offered the bounty for doing this (a year ago!) I imagined that somebody with some relevant experience would simply copy across the plain interp related CMake files and extend them, maybe add a few more bits for the extra files Cog brings in, sprinkle some fairy dust and *foom*! done.

But in the end I don’t care how it’s done, just that it *is* done.

tim

Do you have the time to attempt generating an ARMv6 CMake configuration?
I will be happy to walk you through the process its not hard and pretty intuitive.

Cordially,

tty







Reply | Threaded
Open this post in threaded view
|

Re: No vm-display-x11 Plug-in After Building From Source On FreeBSD 10.1

timrowledge

On 16-12-2014, at 3:49 PM, gettimothy <[hidden email]> wrote:

> Hi Tim.
>
>
> think it was a little after Cog was split off, which explains the dual insanity we have now. I really hope tty is getting close to producing a working CMake setup we can accept to replace the autoblech for Cog. When I offered the bounty for doing this (a year ago!) I imagined that somebody with some relevant experience would simply copy across the plain interp related CMake files and extend them, maybe add a few more bits for the extra files Cog brings in, sprinkle some fairy dust and *foom*! done.
>
> But in the end I don’t care how it’s done, just that it *is* done.
>
> tim
>
> Do you have the time to attempt generating an ARMv6 CMake configuration?
> I will be happy to walk you through the process its not hard and pretty intuitive.

We can try; and a written explanation intended for someone that hasn’t used it before is a pretty good exercise in testing that it actually works.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Fractured Idiom:- MONAGE A TROIS - I am three years old



B J
Reply | Threaded
Open this post in threaded view
|

Re: No vm-display-x11 Plug-in After Building From Source On FreeBSD 10.1

B J
In reply to this post by B J
I decided to do a fresh installation of FreeBSD 10.1, complete with
Mate as desktop and Slim as the login manager.  I then downloaded the
necessary files using subversion and things got interesting.

I noticed after configuring the source code that there was a warning
from cmake about there not being a CMakeLists.txt file in:

/root/Desktop/squeak/platforms/unix/npsqueak

Apparently, CMakeLists.txt has to be in all input directories but
earlier versions skipped it.  But, the current version of cmake
apparently won't allow it unless Policy CMP0014 is set.  I surmised
that by setting that parameter to OLD, I could get around it.

After setting that and then running "make", it appears that everything
was built.  I got no errors and some warnings, leading me to believe
that the parameter was a key factor.

The so.vm-display-X11 plug-in now exists in:

/root/Desktop/squeak/build/vm-display-X11

so that problem appears to be solved.  However, if I run:

/root/Desktop/squeak/build/squeakvm

it can't find it unless I specify that plug-in's location using the
"plugins" parameter to specify its path.  Now it complains that squeak
can't find a sound driver.

What do I do now?

Please advise.  Thanks.

Reply | Threaded
Open this post in threaded view
|

Re: No vm-display-x11 Plug-in After Building From Source On FreeBSD 10.1

David T. Lewis
On Wed, Dec 17, 2014 at 06:51:29AM +0000, B J wrote:
> I decided to do a fresh installation of FreeBSD 10.1, complete with
> Mate as desktop and Slim as the login manager.  I then downloaded the
> necessary files using subversion and things got interesting.
>
> I noticed after configuring the source code that there was a warning
> from cmake about there not being a CMakeLists.txt file in:
>
> /root/Desktop/squeak/platforms/unix/npsqueak

I think that is a harmless warning, so you can ignore it.


>
> Apparently, CMakeLists.txt has to be in all input directories but
> earlier versions skipped it.  But, the current version of cmake
> apparently won't allow it unless Policy CMP0014 is set.  I surmised
> that by setting that parameter to OLD, I could get around it.
>
> After setting that and then running "make", it appears that everything
> was built.  I got no errors and some warnings, leading me to believe
> that the parameter was a key factor.
>
> The so.vm-display-X11 plug-in now exists in:
>
> /root/Desktop/squeak/build/vm-display-X11
>
> so that problem appears to be solved.  However, if I run:
>
> /root/Desktop/squeak/build/squeakvm
>
> it can't find it unless I specify that plug-in's location using the
> "plugins" parameter to specify its path.  Now it complains that squeak
> can't find a sound driver.
>
> What do I do now?
>
> Please advise.  Thanks.

Just install it and give it a try. Do "sudo make install", and run
/usr/local/bin/squeak yourimage.image

Are you doing this all under a root user ID (I notice your build
directory is under /root)? Bad idea, but you can skip the "sudo" part
if you are already root.

Dave


12