Running Shoes on FreeBSD

[IanTrudel]

There are two obstacles for running Shoes on FreeBSD:

1. Building Shoes on Linux instructions are a little light to adapt to FreeBSD. Might be easy, might be hard.
2. FreeBSD provides a very good Linux compatibility where Shoes for Linux may work right out-of-the-box but it doesn't like the Makeself installer. Would it me possible to get a tarball instead? @ccoupe

[ccoupe]

There would different package names (what does BSD use? so finding the correct set of packages is the first challege - find gtk3-dev or whatever they call it. If they don't have packages then building all the deps would be a pain. Building ruby 2.3.3 or below will probably work. Building shoes shouldn't be much of a program . I've alway been bothered by different cp -r vs cp -a on bsd vs linux but thats pretty easy to see when it goes wrong. makeself not supported? It's just shell script if I remember.

[ccoupe]

If the use ELF formatted object files then there is a chance that linux native gems would work. Otherwise you'll have to build them and move them around to be more Shoes like. Not hard but tedious.

[IanTrudel]

Building sounds challenging but FreeBSD provides a good mechanism to fetch, patch and build ports. However, I suspect Shoes for Linux would run just fine. That's the first step anyway.

If the use ELF formatted object files then there is a chance that linux native gems would work. Otherwise you'll have to build them and move them around to be more Shoes like. Not hard but tedious.

Exactly. Normally, a FreeBSD user would do brandelf -t Linux some_elf_file and that's it. Ready to run.

makeself not supported? It's just shell script if I remember.

There are makeself/unmakeself packages to deal with it. I was hoping to avoid that. :)

Basically, running the install results into the following error: eval: ./shoes-install.sh: not found. Any clue?

[ccoupe]

check if shell is bash - bsd used to come with a different shell. That would be real pain.

[IanTrudel]

C shell for root and Bourne shell for users.

The install is working after updating bash path. Same needed for shoes script.

#!/usr/local/bin/bash

Running Shoes causes an error that might outline a potential bug for Linux users. Fixed by linking the file with librsvg-2.so already provided.

shoes-bin: error while loading shared libraries: librsvg-2.so.2: cannot open shared object file: No such file or directory

The following requires gtk3 for Linux. Right now only Linux compatibility gtk2 library package is available. Might need you to send me some prebuilt files.

shoes-bin: error while loading shared libraries: libgtk-3.so.0: cannot open shared object file: No such file or directory

[ccoupe]

So I made a good guess about the shell. That will bite you again. No gtk3 , no Shoes! We stripped the gtk2 code out several versions back and some newer things since then have no gtk2 equivalent.

[IanTrudel]

No gtk3 , no Shoes!

FreeBSD provides a very good Linux compatibility. It means that I can install such libraries as GTK3 in /compat/linux/ (containing Linux filesystem). The problem here is that FreeBSD only provides GTK2 prebuilt. So if I get GTK3 prebuilt, it should be no problem. Same is true for whatever else libraries are needed.

If there is some Ubuntu (or whatever else people use these days) ftp to get such things, let me know. This would be a good news because it's possible to build a FreeBSD ports that will automatically download, patch, compile, install, etc. It could turn very easy to provide Shoes for Linux on FreeBSD, yet low maintenance and without adding a new build to your list.

[ccoupe]

It's sounds a lot like building the deps for windows - it would be similar to building everything in msys2 but slightly easier. Start with gtk, something around older 3.10.9 and see if you get it built to install in your space - not the system. There is wiki article that has all the scripts and links to source code. You'd have to modify the scripts slightly depending on where you store things and where bash is. Once you get the gtk test apps working then you have a chance for success.

[IanTrudel]

My understanding is it would be easier to use binary dependencies and focus on Linux compatibility because it means when you release a new version on Linux, it will work on FreeBSD. Building a native FreeBSD is possible and very similar to Linux but the list of dependencies is so looooooooooong and might require to create a new build target.

[ccoupe]

The problem is on linux libgtk+-3.0.so is in /usr/lib/, system space. And linked to all kinds of other libraries in system space all the way down to libc and crt.so - you can't turn them into usr space libs and linked properly with whats has to be in bsd (libc .....without a whole lot of trouble. If I remember correctly sockets are different, some file handling code is different, time handling code is different. That has to be #ifdef compiled in the various libraries that Shoes uses. I'd be surprised to learn the the elf compatibility layer can do that.

[IanTrudel]

The Linux compatibility provided by FreeBSD makes it so that Linux binaries don't see the difference. They basically think they are running on Linux. For a FreeBSD users, it's happening in /compat/linux, but for Linux compatibility it sees this location as /. Ultimately, whatever I put in /compat/linux/usr/lib will be understood as /usr/lib by the Linux binaries.

[IanTrudel]

I'd be surprised to learn the the elf compatibility layer can do that.

It exactly does that! It's been fully Linux ELF compatible through emulation since late 90s. o_O

[ccoupe]

Testing would be fun - glad it's not me. Install a Linux VM - ubuntu 14.04+ or a recent debian. Install shoes on that. Then copy every thing libshoes.so links to in /usr/ space to the compatibility space of bsd. I forget what the tool is that lists a the linkages from a .so but there is one.

[IanTrudel]

Do you mean copy all the shared object files to /usr/lib? There were included in your installer, which worked after modifying the bash path.

$ ls *.so*
libcrypto.so.1.0.0  libpcre.so.3        libruby.so.2.2      libungif.so.4
libffi.so.5         librsvg-2.so        libshoes.so         libyaml-0.so.2
libgif.so.4         librsvg-2.so.2      libsqlite3.so.0.8.6
libjpeg.so.8        libruby.so          libssl.so.1.0.0

I forget what the tool is that lists a the linkages from a .so but there is one.

readelf -d some_elf_file, objdump -x some_elf_file and ldd some_elf_file (We used those on MacOS X 10.6 build)

$ ldd shoes-bin
shoes-bin:
    linux_vdso.so.1 =>  (0x00007ffffffff000)
    libshoes.so => not found
    libgif.so.4 => not found
    libjpeg.so.8 => not found
    libruby.so.2.2 => not found
    librt.so.1 => /lib64/librt.so.1 (0x0000000800a00000)
    libdl.so.2 => /lib64/libdl.so.2 (0x0000000800e00000)
    libcrypt.so.1 => /lib64/libcrypt.so.1 (0x0000000801200000)
    libm.so.6 => /lib64/libm.so.6 (0x0000000801600000)
    libcairo.so.2 => /lib64/libcairo.so.2 (0x0000000801a00000)
    libpango-1.0.so.0 => /lib64/libpango-1.0.so.0 (0x0000000801e00000)
    libgobject-2.0.so.0 => /lib64/libgobject-2.0.so.0 (0x0000000802200000)
    libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x0000000802600000)
    librsvg-2.so.2 => not found
    libc.so.6 => /lib64/libc.so.6 (0x0000000802a00000)
    libpthread.so.0 => /lib64/libpthread.so.0 (0x0000000802e00000)
    /lib64/ld-linux-x86-64.so.2 (0x0000000800601000)
    libfreebl3.so => not found
    libpixman-1.so.0 => /lib64/libpixman-1.so.0 (0x0000000803200000)
    libfreetype.so.6 => /lib64/libfreetype.so.6 (0x0000000803600000)
    libfontconfig.so.1 => /lib64/libfontconfig.so.1 (0x0000000803a00000)
    libpng12.so.0 => /lib64/libpng12.so.0 (0x0000000803e00000)
    libXrender.so.1 => /lib64/libXrender.so.1 (0x0000000804200000)
    libX11.so.6 => /lib64/libX11.so.6 (0x0000000804600000)
    libz.so.1 => /lib64/libz.so.1 (0x0000000804a00000)
    libgthread-2.0.so.0 => /lib64/libgthread-2.0.so.0 (0x0000000804e00000)
    libgmodule-2.0.so.0 => /lib64/libgmodule-2.0.so.0 (0x0000000805200000)
    libexpat.so.1 => /lib64/libexpat.so.1 (0x0000000805600000)
    libxcb.so.1 => /lib64/libxcb.so.1 (0x0000000805a00000)
    libXau.so.6 => /lib64/libXau.so.6 (0x0000000805e00000)

objdump -x libshoes.so

dynamic Section:
  NEEDED      libgtk-3.so.0
  NEEDED      libgdk-3.so.0
  NEEDED      libatk-1.0.so.0
  NEEDED      libgio-2.0.so.0
  NEEDED      libpangocairo-1.0.so.0
  NEEDED      libgdk_pixbuf-2.0.so.0
  NEEDED      libcairo-gobject.so.2
  NEEDED      libpango-1.0.so.0
  NEEDED      libcairo.so.2
  NEEDED      libgobject-2.0.so.0
  NEEDED      libglib-2.0.so.0
  NEEDED      libgif.so.4
  NEEDED      libjpeg.so.8
  NEEDED      libruby.so.2.2
  NEEDED      librt.so.1
  NEEDED      libdl.so.2
  NEEDED      libcrypt.so.1
  NEEDED      libm.so.6
  NEEDED      librsvg-2.so.2
  NEEDED      libc.so.6

[ccoupe]

Correct, all the so file in installed Shoes will have dependent libs to chase down and copy from a Linux system. Sady, you'll need to decend the tree gathering names for things like libcrypto.so as well. Then you get something to like libX11.so and think "I don't want a second X11. I want to use the BSD X11 lib. How I tell libgtk-3.so.0 to use that. How do I do that?" I have no idea .

The gem issue I raised is a actually different. There are no linux native gems. They always but from source using the systems gcc. Those need to be told to build elf If you are using and elf libruby.so.

If it was me. I'd build a new native target in Shoes terms. use the package manager to install all the packages shoes use. Build your own Ruby. Build your own gtk3 that is linked to the existing bsd (non elf) libs and include it in a working shoes/ruby. A couple of days work and learning. You'll want the knowledge that Shoes can run on BSD.

If you want to play with the compatibility layer try using an older version of Shoes that used gtk2 - federales. If that works, then figure out how to get a gtk3.

[IanTrudel]

It seems you really don't understand the Linux compatibility feature on FreeBSD. The only thing missing from the Linux compatibility is an actual Linux kernel! It even comes with Linux GCC toolchain. Most Linux binaries are working on FreeBSD.

Linux binaries for X11, cairo, etc. are already installed on my system. The only libraries missing from the list above seem to be gtk/gdk 3, libcroco-0.6.so.3, libcairo-gobject.so.2 and possibly a couple more. Looks like something not too far fetched. A native target is a whole lot more work.

[ccoupe]

So all you have to do is build the missing libraries and copy them to the system compatibility place without invoking su/sudo. Go for it! I'm only mentioning road bumps you might find. I'm not telling you what to do. Let's not get another pissing match. I'm telling you what I would do and trouble points I would expect to deal with. Advice, nothing more.

[ccoupe]

I forget to advise that librsvg on linux has a dependency on libcroco and libcairo-gobject may be speed bumps.

[IanTrudel]

Let's not get another pissing match.

Aha. No idea why it ever happens. We accomplished so many things together.

So far the Linux binary dependencies are all available at https://packages.ubuntu.com/artful/.

Ran into a little version problem with several /usr/home/ian/.shoes/walkabout/shoes-bin: /lib64/libc.so.6: version ``GLIBC_2.14' not found (required by /lib64/libgtk-3.so.0).

Also, I noticed libffi 6 was expected but only libffi 5 was provided with Shoes. You may have to double check on your side whether or not it is the correct version.

[ccoupe]

The distributed Shoes is built on a 3 or 4 year old debian chroot so that's where the libffi 5 comes in. Odds are high you grabbed a more recent ubuntu libs tied to libffi 6. glibc difference is also similar only much harder to fix because so may libraries need it. see if you can get the ubuntu libs for 14.04 (aks trusty) which I use to Test the x86_64 linux.

you also need to look at the shoes script that launches shoes-bin. The LD_LIBRARY_PATH may nor may not be correct for what your attempting.

[IanTrudel]

Thanks, very useful information.

I should give a try to what you suggested first. Alternatively, FreeBSD provides compatibility through Linux CentOS 6.9 (legacy) and now CentOS 7.3. The CentOS 7.3 repo contains GTK3 binaries.

It would be really useful to get a map of your dependencies (in your chroot?). One thing is for sure ~ Shoes dependencies on any platform are always so complicated, unclear and such. We might consider opening an issue to clean up and organize dependencies.

[ccoupe]

I would like to know what the centos 7.3 with gtk3 libs does for you on freebsd. If the compatibility layer can handle LD_LIBRARY_PATH (I think it will because it's so common) Then Shoes could work.

There really isn't a solution to dependencies unless you hold them constant for some period of time (like a year to two) which is why homebrew on osx is completely wrong for our purposes (also msys2).

[IanTrudel]

RE: CentOS

The Linux compatibility on FreeBSD is built on CentOS. Several Linux packages are readily available to FreeBSD. Kinda wrappers (download from CentOS repo, patch, install).

RE: dependencies

It might very well be true but it seems that you are the only one actually understanding Shoes dependencies. In fact, I had used dependencies you prepared when I was building on Windows.

System dependencies are not included with Shoes for Linux, which makes it difficult for me to run it with Linux compatibility even though it should be a piece of cake. Furthermore, this whole thing might make it quite complicated to build a native FreeBSD binary despite the fact that a normal FreeBSD desktop machine should have everything it needs (or close to).

Either way it would be a good thing to clarify dependencies. No solution? We could use those tools to list dependencies on Linux and build a map. This would be a good start.

What do you think?

[ccoupe]

Several Linux packages

Hmm, I don't see gtk3 at that link but documentation is always the last thing to fix.

System dependencies are not included with Shoes for Linux, which makes it difficult for me to run it with Linux compatibility even though it should be a piece of cake. Furthermore, this whole thing might make it quite complicated to build a native FreeBSD binary despite the fact that a normal FreeBSD desktop machine should have everything it needs (or close to).

We are dealing with a hybrid or a new target. Nothing will be easy until the secret is found. No different than getting Shoes working on a mips arch board. Dependencies are platform specific. Neither Apple, Microsoft or the linux's and bsd's have solved that problem. Some are better than others but you work with what you have knowing it's probably going to be worse than you think. What version of freebsd are working with? 32 or 64. Why freebsd and not netbsd or openbsd ? Do they all have this linux compatibility layer?

The task you want to accomplish is running distributed Shoes/Linux on freebsd. Correct?

My approach is to build up incrementally from one success to another instead of top down hope and unmet expectations. That's why I'd start with federales 3..2.25) the last of gkt2 based shoes that might possibly work on your existing freebsd. Do the simplest thing first and learn from that.

[IanTrudel]

RE: Federales

Good news! Your approach is indeed successful.

Shoes Federales 64bits, libfreebl3.so (CentOS 6.9 for Linux C6 compat; copied into /compat/linux/lib64), unmakeself, changing bash path in shoes-install.sh and shoes for /usr/local/bin/bash. Plus various linux-c6 packages for Xorg that was already installed on my system for other common Linux software.

RE: GTK3 package

It's currently not available in FreeBSD ports but it's the same mechanism as GTK2. I would just have to copy it and point to GTK3 libs on CentOS 7 repo. That is, if I know which packages to get.

RE: Dependencies

We would have long term advantages to clarify and understand Shoes dependencies. It might not be as complicated as it seems but right now it's not so easy to create a new target. The wiki is not helping when it comes to dependencies. There is not even a list anywhere that would say "get those packages and you should be on your way".

To be very clear to you ~ I feel rather clueless about Shoes dependencies. Not a good sign!

RE: FreeBSD

Currently running FreeBSD 11.1 64bits. It might be surprising to you because we mostly talk about Windows but I am a long term FreeBSD user since mid 90s; mostly on servers but occasionally desktops. Even ported commercial software to FreeBSD. If you recall mid 90s, Linux wasn't much of a thing but FreeBSD was the backbone of the Internet.

The BSD family is different from Linux where BSDs are specializations rather than distros. OpenBSD focuses on security, NetBSD on portability and hardware compatibility, PCBSD (now TrueOS) on desktop and FreeBSD on server and networking.

Because BSDs are so tight knitted, they are usually fairly compatible and they heavily share code amongst each other. Code are being integrated at a higher rate than in the Linux world of distros, though always according to the BSDs focus of interest.

The task you want to accomplish is running distributed Shoes/Linux on freebsd. Correct?

Yes, I think it is the simplest and easier approach. If there would be a need or demand for a native FreeBSD version, that could be arranged but it seems a bit overkill considering the burden of adding to your build cycle and Linux compatibility should be fine.

I could create a FreeBSD port that would automatically download the Linux version and install it on FreeBSD. That might introduce new users to Shoes and yet without much hassles for either of us.

[ccoupe]

Succees! ! Love it.

I don't build dependencies for Linux. I just install the packages. Ubuntu or Debian maintainers do all the which library works with what. For Mingw, I do all the version-ing and compiling. wiki. Also the dependencies for OSX 10.9 has an article. 10.9 might be closer to freebsd . Your freebsd has a mix of existing libraries and missing libs. If you grab an older Gtk 3 you'll probably have less version-ing trouble. Just grabbing a ubuntu lib or two is a little risky unless you discover what there was built to use. - the libc glib 2.14 warning constrains you to a range of Gtk3 numbers. Shoes is not particularly sensitive to which version of cairo or pango or pangocairo or pixbuf

Indeed, I do remember the Att sys 5 vs BSD based days. I still have the series DDJ magazines describing an early bsd for 386.

[IanTrudel]

I don't build dependencies for Linux. I just install the packages.

What about chroot you mention on the wiki?

Following your lead, I am installing a FreeBSD virtual machine (found here) to do some experiments.

The GTK 3 might not have been the right version to test with. You did mention to use trusty rather than arty. Also suspecting that using CentOS binaries would be even better.

Indeed, I do remember the Att sys 5 vs BSD based days. I still have the series DDJ magazines describing an early bsd for 386.

The good ol' days.

[IanTrudel]

[ccoupe]

Excellent !! I was about to create a freebsd VM in case I need to follow along. Clearly I don't need to but I probably will.

[IanTrudel]

Thanks for your feedback. It did clarify and eventually I made it.

Here is my raw notes if you want to give it a try.

https://download.freebsd.org/ftp/releases/VM-IMAGES/11.1-RELEASE/amd64/Latest/ https://www.freebsd.org/doc/handbook/virtualization-guest-virtualbox.html https://www.freebsd.org/doc/handbook/x11.html https://www.freebsd.org/doc/handbook/x11-wm.html (if you need a wm) https://www.freebsd.org/doc/handbook/linuxemu-lbc-install.html

pkg install xorg
pkg install linux_base-c7 linux-c7-cairo linux-c7-pango linux-c7-atk linux-c7-gdk-pixbuf2 linux-c7-libxml2 linux-c7-dbus-libs linux-c7-dbus-glib
pkg install unmakeself bash
dbus-uuidgen > /var/lib/dbus/machine-id

Enable Linux compatibility https://www.freebsd.org/doc/handbook/linuxemu-lbc-install.html

kldload linux
kldload linux64
ee /etc/rc.conf
linux_enable="YES"

http://mirror.centos.org/centos/7.3.1611/os/x86_64/Packages/

Download following packages and extract (using tar xvf) then cp -R * /compat/linux :

http://mirror.centos.org/centos/7.3.1611/os/x86_64/Packages/gtk3-3.14.13-20.el7.x86_64.rpm http://mirror.centos.org/centos/7.3.1611/os/x86_64/Packages/cairo-gobject-1.14.2-1.el7.x86_64.rpm http://mirror.centos.org/centos/7.3.1611/os/x86_64/Packages/nss-softokn-freebl-3.16.2.3-14.4.el7.x86_64.rpm http://mirror.centos.org/centos/7.3.1611/os/x86_64/Packages/libcroco-0.6.8-5.el7.x86_64.rpm http://mirror.centos.org/centos/7.3.1611/os/x86_64/Packages/at-spi2-core-2.14.1-2.el7.x86_64.rpm http://mirror.centos.org/centos/7.3.1611/os/x86_64/Packages/at-spi2-atk-2.14.1-1.el7.x86_64.rpm

Use unmakeself on Shoes Walkabout 64bit installer to extract it. Edit using ee to change bash path to /usr/local/bin/bash and possibly edit LD_LIBRARY_PATH. Shoes is looking for librsvg-2.so.2 but only librsvg-2.so is bundled with it (mistake?), so I did a ln -n librsvg-2.so librsvg-2.so.2

Not too bad, isn't it?

[IanTrudel]

Well, it's not working so well on a live system. Something seems to interfere. Any clue?

The libyaml is a FreeBSD executable. It shouldn't use this.

/usr/local/lib/libyaml-0.so.2: Système d'exploitation du fichier ELF ABI invalide - /usr/home/ian/.shoes/walkabout/lib/ruby/gems/2.2.0/gems/psych-2.2.2/lib/psych.so
-e: [BUG] Segmentation fault at 0x00000000000018
ruby 2.2.7p470 (2017-03-28 revision 58194) [x86_64-linux]

Occasionally get this warning:

** (shoes-bin:37949): WARNING **: Couldn't register with accessibility bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

[IanTrudel]

Fixing bus error: export NO_AT_BRIDGE=1

http://computing.help.inf.ed.ac.uk/accessibility-bus

[IanTrudel]

So, native FreeBSD libyaml package is interfering with Shoes. What is life without vim though?

[ccoupe]

a VIM less world would be a nightmare for me. I'll update the launch script template for NO_AT_BRIDGE=1 -- The same problem happens on a pi3/raspbian.

It should have found our libyaml first but ours has a different name so maybe that needs to be fixed at Shoes.

[IanTrudel]

Good. Do you remember we had hardcoded path problems with libraries on MacOS X? You processed the libraries to avoid the problem. Perhaps psych.so needs such treatment too.

[ccoupe]

I'm speculating - here the libyaml linkages

(debx86)ccoupe@bronco:/usr/lib/x86_64-linux-gnu$ ls -ld libyaml*
lrwxrwxrwx 1 root root     18 Dec 13  2014 libyaml-0.so.2 -> libyaml-0.so.2.0.2
-rw-r--r-- 1 root root 129280 Dec 13  2014 libyaml-0.so.2.0.2
-rw-r--r-- 1 root root 172920 Dec 13  2014 libyaml.a
lrwxrwxrwx 1 root root     18 Dec 13  2014 libyaml.so -> libyaml-0.so.2.0.2

Odds are high that the .so with all the code is the name embedded inside. I copied one of the symlinks. I'm guessing linux tries a few name variations to find things a perhaps bsd doesn't. You could test that by renaming the shoes libyaml properly and reinstall freebsd's 1.6.0. To be safe I'll check all libname to use the real file and not a symlink. That will cause a curl problem but I can fix that.

[ccoupe]

I've tried a shoes launch script that has the first line of

#!/usr/bin/env bash

It works on linux. Does it work on freebsd?

[IanTrudel]

You could test that by renaming the shoes libyaml properly

libyaml-0.so.2, libyaml-0.so.2.0.2 and libyaml.so are not making any difference.

Which library needs libyaml anyway?

a VIM less world would be a nightmare for me.

One thing we agree on. :D

What does your vimrc look like?

#!/usr/bin/env bash It works on linux. Does it work on freebsd?

Excellent, sir. This is working here.

[ccoupe]

Which library needs libyaml anyway? Ruby stdlib - require 'yaml'

What does your vimrc look like?

more ~/.vimrc 
set ts=4
set et

Primitive. I like vi because it's always on unix (grr to msys). I only have to know a handful of keystrokes to make a quick fix to something like /etc/fstab. Any thing complicated and I switch to a GUI editor. I have no opinion about vi vs emacs - too old care about that war.

You can try Shoes 3.3.4 beta. It has the changes about (env bash), better library names. Has typhoeus and curl but they aren't used by Shoes.

[IanTrudel]

Ruby stdlib - require 'yaml'

Ewh. I was hoping it would be listed as a dependencies but it's dynamically loaded.

Primitive. I like vi because it's always on unix (grr to msys). I only have to know a handful of keystrokes to make a quick fix to something like /etc/fstab. Any thing complicated and I switch to a GUI editor. I have no opinion about vi vs emacs - too old care about that war.

Very similar here. Though I enjoy regexp in vim very much and use it on Windows as well ~ install gvim for windows to use with msys :)). Notepad++ is good but there are things vim can do that no other can.

Never had a debate about vi vs emacs. We simply use what we like, right?

You can try Shoes 3.3.4 beta. It has the changes about (env bash), better library names. Has typhoeus and curl but they aren't used by Shoes.

Alright, I will give it a try and report.

[IanTrudel]

It is working but I had to rename (or ln -n) the following files libgif.so.4.1.6, libjpeg.so.8.4.0, librsvg-2.so.2.36.1, libyaml-0.so.2.0.2 into libgif.so.4, libjpeg.so.8, librsvg-2.so.2, libyaml-0.so.2. Otherwise it really won't find any of them.

The changes allow Shoes and vim/libyaml to coexist. You made the world a better place. Thanks.

Also, cobbler is not working as a user but it is working as root.

./shoes -c
Permission non accordée @ rb_sysopen - /dev/null

This also brings me to an important question. Let's say we would create a FreeBSD ports for everyone to be able to install Shoes easily. It's something to do as a root user. How would that play out to properly install it so every user can use it? (Right now, your shoes-install.sh script install it in ~.shoes/...).

[ccoupe]

Thanks for confirming that the symlinks are the problem (and the solution). Was there a complaint about libcurl? -- it should have a couple of symlinks inside. Very important info. Why?

This goes way back to Shoes/Raisins which used minitar.rb to build/expand Shoes - minitar doesn't do symlinks. I use the tar inside of rubygem which I believe does transfer symlinks. Painful to test.

The solution in the latest commit on branch rb23 is not optimal.

[IanTrudel]

Curl is most likely loaded dynamically and thus any problems are postponed until it is loaded and used. Need to test.

Spinner is not displaying but the tooltip shows up where it should be. Switch is working fine.

[IanTrudel]

Generally Shoes for Linux behaves as you would expect on FreeBSD. There are occasional crashes and hang up but no repeatable scenario so far. It might be difficult to debug without native build though. The biggest annoyance is when Shoes crashes, it hangs and leaves shoes-bin in dbus wasteland that won't terminate unless you send a hundred of -9 signal or so to its process.

9871 5 T+ 0:25,23 /usr/home/ian/temp/shoes/shoes-bin (dbus)

Samples are working fine. Systray is really nice addition. Funnies is not working (and a mild warning).

Warn in <unknown> line 0 | 2017-08-27 18:54:47 -0400
WARNING: Nokogiri was built against LibXML version 2.9.4, but has dynamically loaded 2.9.1

samples/good/downloader

• Percentage is wrong (needs to be multiplied by 100)
• Cancel doesn't work
• Would be better 295 KB/s, 38 seconds.

[ccoupe]

As I type, freebsd is compiling its head off to get virtualbox-ose-additions built. Compiling everything in the FSF catalog including gcc plus perl and python and ....

Yes, a Shoes port is going to be helpful to debug things.

[IanTrudel]

FreeBSD ports is great but if you want to install binaries, you could just do: pkg install virtualbox-ose-additions. Use pkg search <keyword> to search amongst packages.

[ccoupe]

I tried that earlier and I never got an X11 to work with. Old instructions? This time I did get a prompt to install x11 so there is hope.

[IanTrudel]

pkg install xorg should have been fine. Which instructions did you follow?

[ccoupe]

Someone didn't read all of your instructions before proceeding. Oh well, as they say, I know more about what's in the system now.

Curl is most likely loaded dynamically and thus any problems are postponed until it is loaded and used.

It appears that when Ruby inits , it makes a pass through all the gems inside Ruby which can trigger crashes if a gem doesn't have the native library. Seen it. Caused it.

[IanTrudel]

Alright. By the way, binary packages and ports are unified on FreeBSD. Either way pkg info will list both once installed.