[Vm-dev] build.minheadless.cmake/x86/pharo.cog.spur -- cannot open libwinpthread-1.dl

Ben Coman btc at openinworld.com
Sat Dec 1 04:24:46 UTC 2018


On Sat, 1 Dec 2018 at 07:46, Ronie Salgado <roniesalg at gmail.com> wrote:

>
> Hello,
>
> When I started making the minheadless version I wanted to nuke all of the
> platform specific code, and unify it as much as possible. For building I
> adapted the hand written CMake scripts that I normally use for my projects.
> One of my motivation for CMake is on using MSVC for building on Windows,
> which is also a requirement in order to support the UWP for running the VM
> in a retail Xbox One.
>
> Before folding back into opensmalltalk, Pharo actually had a CMake helper
>> to build the VM with options etc.
>> This was deemed too complicated and people steered towards a vanilla
>> makefile.
>>
> Pharo was NOT using CMake.  Pharo was generating cmake scripts from the
> image, which then they were being used for compiling the VM. That is
> definitely a complicated and not a proper way of cmake.
>
> Now, yes, build times are long. But because there are a lot of
>> dependencies being built as part of the whole.
>> There are some optimisations yes, like not rebuilding, say, FreeType on
>> every build.
>>
> And also plugins. Many plugins do not make sense as being part of the VM.
> There are not properly maintained or used. In Pharo at least there is the
> tendency of moving as much functionality as out of the plugins, and
> replacing them with libraries that called via the FFI.
>
> Is is a pendulum swing in action?
>>
> Well, with Esteban we decided one year ago that in order to reduce
> friction with the community, to use cmake only for configuration purpose
> (i.e replace autoconf to generate a config.h), and to keep using the
> existent makefiles. We already adapted the makefiles from Linux and Mac for
> Pharo. Handling dependencies during the build process is also another
> motivation for keeping the makefiles.
>
> As for me, I prefer to just use cmake for the whole build process. In my
> opinion, I think that we are suffering from the lack of proper separation
> between the core VM, and user specific features (e.g: freetype, cairo,
> midi, mp3 player, etc) that should be isolated as much as possible from the
> vm. The VM itself should be a virtual processor and memory manager, it
> should not be a full operating system with 3D graphics, joystick support,
> midi controller plugin interface. Those other features are not the
> responsibility of the VM.
>
> I just submitted a pull request that fixes the build with cygwin for win32
> ( https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/311 ).
>
During the weekend I will write proper documentation on how these cmake
> scripts are supposed to work. Normally it should just be a matter of
> issuing the following commands on the top-level directory:
>
> mkdir build
> cd build
> cmake ..
> make
>
> and then for development just use make, and some occasional make clean.
> The scripts in build.minheadless.cmake are in place to automate this
> process and for building all of the variants of the vm. Cygwin is a bit
> trickier because it is treated as an Unix instead of Windows. Cygwin
> requires some additional command line options because it requires settings
> cmake in cross compilation mode by passing a toolchain file to cmake. The
> scripts in build.minheadless.cmake/x86|x64/<vm variant>/ already take care
> of detecting the usage of Cygwin, and passing the proper command line
> options to cmake.
>

I fetched it down. The build worked...
$ cd pharo.cog.spur
$ ./mvm
[100%] Built target pharo
$ cd release/dist
$ ls
libpharo.dll.a  libPharoVMCore.a  libpharow.dll.a  pharo.exe  pharow.exe

But then...
$ ./pharo.exe
produces error... "while loading shared libraries: libwinpthread-1.dll:
cannot open shared object file: No such file or directory"

And from CMD.EXE side running "pharo.exe" produces two system error
pop-ups...
"The code execution cannot proceed because libfreetyupe-6.dll was not
found."
"The code execution cannot proceed because libwinpthread-1.dll was not
found."

I'll start hunting around, but anyone have some ideas?

cheers -ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20181201/5ddc4484/attachment.html>


More information about the Vm-dev mailing list