The version of Guile in -current is 1.8.8, released in December 2010. There have been no further developments to the 1.8 branch since that release.

The 2.0 branch of Guile started in February of 2011. There have been nine additional releases since that time and currently Guile is well-tested and stable. Future releases in the 2.0 branch will likely comprise only bugfixes and general code maintenance (a 2.2 branch has been started for more experimental development).

It would be nice if the next release of Slackware could be updated with a more recent version of Guile.

+1 for this

The transition from 1.8 to 2.0 does not seem to be a smooth one or very backwards compatible. I'll be happy with guile 2.0 when the programs out there that use guile also upgrade their scripts to use guile 2.0. Until then, even if Pat upgrades Slackware's guile to 2.0, I'm sticking with 1.8, not knowing what to do with guile when guile breaks. I'd rather have a guile that works than one that does not work.

You raise a valid concern, mlslk31. Here is my understanding of the current state of things with regard to updating to Guile 2.0.

To my knowledge, there are no packages in Slackware -current that would be broken by the upgrade. The SWIG interface library did not support Guile 2.0 prior to version 2.0.10, but -current is now shipping SWIG 2.0.10.

There are some SlackBuilds from slackbuilds.org that will be affected. The version of Xbindkeys (version 1.8.5) specified by the Slackware 14 SlackBuild is already compliant with Guile 2.0 and thus should not present a problem.

The version of Ardour (version 2.8.14) specified by the Slackware 14 SlackBuild successfully builds and runs against Guile 2.0 but it is possible that there are a couple of scripts that still need updating. Any such bug would only mean the loss of that particular script's functionality, and the Ardour developers have been very diligent in addressing these issues.

There is no SlackBuild for the GNOME card game AisleRiot but for those who wish to build their own package, Guile 2.0 may present a problem as the AisleRiot changelogs do not appear to mention any changes driven by Guile 2.0 support. This does not necessarily mean that Guile 2.0 is incompatible. The big change in Guile 2.0 that has been causing grief is that macros can no longer be used before they have been defined (Guile 1.8 was forgiving of this). If no such undefined macros are used then backwards compatibility with Guile 2.0 should not be a problem. Guile is used by AisleRiot only for generating the HELP system; not to trivialize this, however, the games should still work without help being available.

There is also no SlackBuild for the Dr GEO geometry program, which has Guile 1.8 as a dependency. I am completely unfamiliar with this program, and have no idea whether it would be impacted by an upgrade of Guile to 2.0.

The SlackBuild for GNUcash is currently at version 2.4.11, which will not build against Guile 2.0. Support for Guile 2.0 is available in GNUcash version 2.5.2 of the development branch. I imagine SB.o would prefer to stay with the stable 2.4 branch but I believe there have been exceptions made in the past.

One of the more problematic programs would be the Lilypond music notation software. Its SlackBuild for SW 14.0 specifies version 2.16.1 and, as was the case for GNUcash, this would need to be bumped up to the 2.17 development branch to work with Guile 2.0. The Guile-driven changes in the 2.17 branch are too extensive to expect that they'd be backported to the 2.16 branch.

Lilypond also presents a problem in that the Slackware 'texi2html' utility (included in the Tetex 3.0 package would need to be upgraded from version 1.76 to version 1.82 in order for Lilypond 2.17.20 to work with Guile 2.0. Other than the Guile package itself, Tetex is the only other package in Slackware proper that should need upgrading.

That is my best assessment of the impact upon Slackware of upgrading to Guile 2.0. If I have made a mistake or have missed anything, please let me know.

1 members found this post helpful.

Yep, AisleRiot and GNUCash are the ones where Guile 2.0 burned me last time. The incompatibilities are getting resolved with time, it's just a very slow process.

I don't know Guile, though. Can two Guile interpreters exist side-by-side in any kind of harmony? That whole Python 2.x/3.x thing doesn't give me much confidence in this approach, though it's better than it was this time last year.

I failed to mention another change in Slackware that would be necessary. Slackware should need to include a package for the GNU libunistring library. I'd thought that was already added in -current, but I don't see it there.

I have not tried that but will look into it next week. Given that Guile 2.0 is more intimately tied to the installed system (being a compiler instead of an interpreter), I strongly suspect it would be much easier to add a non-conflicting Guile 1.8 to a system with 2.0 than the converse.

Changelog.txt (for -current)

Thank you, Pat.

Why the upgrade??? Seems Guile 2 BREAKS several SBo packages, namely SLIB, which is needed by Gnucash. Forced me to blacklist it until things are fixed.

Sorry, just my $.02...

Please note that SBo are guaranteed to work with stable releases only
When you are using -Current, things *might* break at some point, but it should be fixed when the maintainer updated their script to work with a new release (14.1) soon

@Lenard Spencer

According to the Guile developers, version 1.8 can co-exist with 2.0. You may wish to try that.

Otherwise, if you update your Slackbuild for slib from slib-3b2 to slib-3b4 then any release of GNUcash from its 2.5 development branch (2.5.6 is the latest) should work with Guile 2.

gnucash is a requirement for my business. If I can't get it to work under 14.1 it will be a show stopper for me.

How do I arrange for and will that be the only problem for gnucash?

Alex

I just tried it, and it failed miserably. Slib SEEMED to build, but threw a couple "ignored" errors during the build. And the install was a complete disaster. Even the old slib build (under 1.8) failed the install with both Guile's in place.

So for now, I'm blacklisting Guile-2.0.9 unless there is an absolutely compelling reason for me to upgrade.

As far as Gnucash 2.4, it has other issues with 14.1 (libbonobo won't build either because of glib2), but that's the subject of another thread.

Thanks for the updates which seem to indicate that upgrading to 14.1 might be a rocky ride for gnucash.

I've got a two disk machine, one disk currently has 13.37 the other 14.0. 13.7 will be wiped with a new install of 14.1 so I will still have a working version of 14.0 if 14.1 looks a non starter for me. Hopefully, sometime in the future everything will again line up!

Alex

Were you building slib-3b4, or using an unmodified Slackbuild from SB.o (based on 3b2)?

Also, how did you handle the naming of the binaries being the same in both Guile Slackware packages? When the upstream developers say they can co-exist, that does not necessarily mean the corresponding distro packages can. Some means of recognizing the distinction between the Guile 2.0 and Guile 1.8 binaries needs to be introduced (since they are both named 'guile' within the Slackware packages).

What probably needs to happen is to, along the lines of what Fedora has done, modify Patrick's 14.0 Guile Slackbuild to produce a 'compat-guile-1.8' package wherein the binaries (guile, guile-config, guile-snarf, and guile-tools) are given names unique from those in the 14.1 Guile package. After this compatibility package is installed (alongside Guile 2.0) in 14.1, any third-party Slackbuilds that require building against Guile 1.8 (e.g., GNUcash) would need to be modified to explicitly call out the Guile 1.8 binaries (the pkg-config and libraries appear to have no naming conflicts). And, of course, the SLIB Slackbuild for 14.1 should be updated to version slib-3b4.

I will be installing RC2 this evening and will try to test the above approach over the next few days.