Gauche Devlog

< To quote or not to quote | Release and test >


New directory structure

Until 0.9, you had to recompile Gauche extensions for every new release of Gauche, even if it was a micro version up (i.e. 0.8.12 -> 0.8.13). It was because C API could be changed between them.

After 1.0, it is our goal to keep API & ABI compatibility at least for minor version level, so that extension modules compiled for version X.Y.z1 will work for X.Y.z2 where z2 >= z1. 0.9.x series is the run-through rehearsal for the stable 1.0 release, to see our scheme really works after 1.0.

At 0.9 release, however, I overlooked one thing: Full Gauche version number (major.minor.micro) was embedded in the pathnames where architecture-depended files are installed; extensions' DSOs are in /usr/lib/gauche/site/X.Y.Z/${arch}/ (if Gauche was installed with --prefix=/usr.) This wouldn't work if we want to share extensions among different micro versions.

An easy way could be to keep using "0.9" throughout 0.9.x series for the 'site' directory. That is, while Gauche "core" files would still go to /usr/lib/gauche/X.Y.Z/${arch}/, extension modules install their files to /usr/lib/gauche/site/X.Y/${arch}/. Version 0.9's structure already fit this scheme, so transition would be smooth.

However, this scheme somewhat mixed gauche version (X.Y.Z) and ABI version (X.Y). That is, in /usr/lib/gauche/0.9/, the "0.9" part would mean gauche version, while in /usr/lib/gauche/site/0.9/, the "0.9" part would mean ABI version. It might not matter in practice, but I didn't quite like such mixture.

And there came another issue: The Gauche runtime DSO ( is placed in the system's common library directory, such as /usr/lib. It is common to append versions after the name (e.g. and and make versionless name a symlink to the versioned name. However, the common assumption for this scheme is that binary compatibility is kept among the same major versions; if something is compiled with, it is expected to work with as well. At this moment I want to reserve the possibility to change ABI between Gauche version 1.0 and 1.1.

So, I decided to name the Gauche runtime DSO as, where X.Y is the ABI version. Then it is clear that which version is compatible to which DSO. It also allows to install more than one versions of Gauche with different ABI versions.

If we name DSO as libgauche-X.Y, then why don't we name other runtime libraries as well? That is, we can install stuff under /usr/lib/gauche-X.Y/ and /usr/share/gauche-X.Y. Then it is clear that which ABI version the file(s) are for, and it is easier to manage when you have multiple versions of Gauche with different ABI versions (e.g. it's easy to delete files for old versions).

So, from 0.9.1, I adopt the following naming scheme:

  • Gauche runtime DSO
    • ${exec_prefix}/
    • ${exec_prefix}/ (soname)
    • ${exec_prefix}/ (realname)
  • Architecture dependent files
    • ${exec_prefix}/gauche-X.Y/X.Y.Z/${arch}/* ;; core's *.so
    • ${exec_prefix}/gauche-X.Y/X.Y.Z/include/* ;; core's *.h
    • ${exec_prefix}/gauche-X.Y/site/${arch}/* ;; extensions' *.so
    • ${exec_prefix}/gauche-X.Y/site/include/* ;; extensions' *.h
  • Architecture independent files
    • ${datadir}/gauche-X.Y/X.Y.Z/* ;; core's *.scm
    • ${datadir}/gauche-X.Y/site/* ;; extensions' *.scm

During 0.9.x period, the old versionless directories are automatically added to the library search path, and symlink are created from etc. to the versioned DSOs. So, the extension modules you've installed for Gauche 0.9 should keep working after you install 0.9.1.

(Note for those who are chasing development trunk: If you've installed extensions for 0.9.1_pre1 or 0.9.1_pre2, the official 0.9.1 release may not be able to find them, since I tweaked structure at the last minute. Sorry.)

Tags: 0.9.1, DirectoryStructure

Past comment(s)

ASchemeUser (2010/12/12 08:42:47):

Can't yuou use SONAME for that? SONAME field is specifically designed to specify the ABI version. So library name could be irrespective of library version.

shiro (2010/12/12 10:57:06):

Maybe, though what I see is that typical SONAME uses single digit to specify ABI version. My understanding of that part is pretty vague, though. Could you point some documentations to explain how SONAME can be used in the real-world situation?

Post a comment