Skip to content

Conversation

lukego
Copy link
Contributor

@lukego lukego commented Apr 3, 2016

This is a work in progress attempt to make Cairo (libcairo) available in Pharo.

The specific problem I see is that when I run the Moose 6.0 image then Roassal does not work. Can reproduce by opening Roassal Examples from the World menu and clicking to open one. The problem is that Pharo tries to dynamically load libcairo from a few hard-coded locations (none of which are suitable with nix).

Here is the local hack that I am using right now to make this actually work:
pharoscreenshot 1

Any tips on how to do this properly @DamienCassou?

@mention-bot
Copy link

By analyzing the blame information on this pull request, we identified @DamienCassou to be a potential reviewer

@DamienCassou
Copy link
Contributor

@lukego How is propagatedBuildInput helping you? Which additional change do you do in your image to make this work? What I do is that I execute this bash function:

function libcairo32 () {
    find /nix/store/*cairo* -name 'libcairo.so*' | xargs file | grep 'ELF 32' | head -n 1 | cut --delimiter=':' --fields=1 | xclip -in -filter -selection clipboard
    echo "Path to libcairo.so 32bits copied to clipboard"
}

It copies in the clipboard the path to the .so file. This means you have to manually fix all your new images and you have to fix all your old images each time you garbage collect the nix paths. This is far from satisfactory. A better solution would be:

  • all VMs come with a specific text file that would map library names to paths. Something like:

    {
        "cairo": "/nix/store/..",
        "libgit2": "/nix/store/..."
    }
  • then, the image would look into this file before trying hard-coded paths

@DamienCassou DamienCassou added the 0.kind: enhancement Add something new or improve an existing system. label Apr 3, 2016
@DamienCassou DamienCassou self-assigned this Apr 3, 2016
@DamienCassou DamienCassou changed the title pharo vm: Add cairo as runtime dependency [wip] pharo vm: Add cairo as runtime dependency Apr 3, 2016
@lukego
Copy link
Contributor Author

lukego commented Apr 3, 2016

Thanks for the feedback! The propagatedBuildInput idea was a wild guess at how to register Cairo as a runtime dependency and GC root. I have no idea if it actually had any effect. The change I did to make things work was manually modifying the image to look for a hardcoded path into my Nix store.

Could LD_LIBRARY_PATH also be a solution here? Or statically linking Cairo?

The ideal would be a solution that does not require image modifications but I don't have any ideas for that.

Just now my goal is to run other people's images and so it is basically okay to do fragile hacks like in my screenshot above. In the future though I may want to distribute my own images with nix and then I would like to know how to do that in a reliable way.

@lukego
Copy link
Contributor Author

lukego commented Apr 3, 2016

I am closing this PR since it is serving mostly as a vehicle to ask a question ("How should I package a Pharo image with Nix?") rather than leading to mergable code.

@lukego lukego closed this Apr 3, 2016
@DamienCassou
Copy link
Contributor

I think the most reliable way is the one I suggest above. The image reads a text file that is distributed with the VM.

@lukego
Copy link
Contributor Author

lukego commented Apr 20, 2016

I have a follow-on question if I may take up more of your time --

I have a first "alpha" version of a Pharo application that I want to distribute now. I would like to make it very easy to install on Linux and OSX. I am thinking that nixpkgs is a suitable distribution mechanism. (I know that Pharo has other options but I have found them a bit painful personally.) This is a graphical thingy that depends on Cairo (some details at snabbco/snabb#873 (comment) if you are curious).

The first thing I need to do is make my image find libcairo. If I understand correctly I should update the derivation that builds the Pharo VM to create a text file listing the location of the libraries. Is that correct? (Or would I do this with a new derivation that separately creates just the text file?) If you have any hints on how to do this I would be grateful - including at what path I could store this text file such that the image can find it.

The second thing I need to do would seem to be automating the bootstrapping of the image. Just now I have started with the Moose-6.0 image (~100MB w/ changes file) and then hacked on that (somehow my image has ballooned to 942MB). I probably need to start with a more streamlined base image, run some headless code to merge in the right version of my software and run the test suite, then produce a modestly sized image for nixpkgs. Does that sound right? This would be a longer term activity but any relevant links would be appreciated!

@DamienCassou
Copy link
Contributor

DamienCassou commented Apr 21, 2016

I have a follow-on question if I may take up more of your time

sure

I have a first "alpha" version of a Pharo application that I want to distribute now. I would like to make it very easy to install on Linux and OSX. I am thinking that nixpkgs is a suitable distribution mechanism

I agree, but not for Windows. The problem with Pharo, is that it ships with different source files for Linux and OS X. Currently, the pharo-vm nixkgs derivation only builds the sources for Linux (http://files.pharo.org/vm/src/vm-unix-sources/blessed/). Work must be done if nixpkgs is going to be used to install Pharo on OS X.

(I know that Pharo has other options but I have found them a bit painful personally.)

the PharoLauncher has a Windows installer, an OS X dmg and Linux packages for several distributions. That's the more user friendly because this is what users typically expect on each platform.

Look here for more information:

The first thing I need to do is make my image find libcairo. If I understand correctly I should update the derivation that builds the Pharo VM to create a text file listing the location of the libraries. Is that correct?

yes

(Or would I do this with a new derivation that separately creates just the text file?

no, it can be part of the same derivation

) If you have any hints on how to do this I would be grateful - including at what path I could store this text file such that the image can find it.

@@ -21,6 +21,10 @@ stdenv.mkDerivation rec {
     mimeType = "application/x-pharo-image";
   };

+  libraries = ''
+    cairo=${cairo}
+  '';
+
   # Building
   preConfigure = ''
     cd build/
@@ -66,6 +70,8 @@ stdenv.mkDerivation rec {
     chmod +x $prefix/bin/${binary-basename}-x $prefix/bin/${binary-basename}-nox

     ln -s "${pharo-share}/lib/"*.sources $prefix/lib/$name
+
+    echo $libraries > $prefix/lib/$name/libraries.txt

The second thing I need to do would seem to be automating the bootstrapping of the image. Just now I have started with the Moose-6.0 image (~100MB w/ changes file) and then hacked on that (somehow my image has ballooned to 942MB).

do you have a configuration? That's the first and most important step. Read the Metacello chapter of the Deep into Pharo book. You can generate a configuration using Versionner (provided with all Pharo images).

I probably need to start with a more streamlined base image, run some headless code to merge in the right version of my software and run the test suite

use our Jenkins servers to build that automatically: https://ci.inria.fr/pharo-contribution/. You can copy the JobTemplate template.

, then produce a modestly sized image for nixpkgs. Does that sound right?

that's what I would do

This would be a longer term activity but any relevant links would be appreciated!

please continue asking me questions. But maybe emails (private or in a mailing list) would be more appropriate.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

0.kind: enhancement Add something new or improve an existing system.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants