On Feb 22, 2011, at 07:00, Hans Aberg wrote: [quoting others...] >>> I noticed that that is possible - in fact, to make sure to get it right, I >>> removed all Guile headers in /usr/local/include/ and reinstalled guile-2.0. >>> >>> The Guile 1.8 header libguile.h is in /usr/local/include/, but the one from >>> 2.0 is in /usr/local/include/guile/2.0/. Both directories are included when >>> compiling. So if the include order is wrong, or the from 2.0 is somehow >>> excluded, you may get the wrong one, and it may in fact compile. >>> >>> Perhaps 2.0 should have some check that it gets the right header.
It wouldn't be that tough to do something like: #define scm_init_guile scm_init_guile_v2_0 // encode version in symbol or #define scm_init_guile scm_init_guile_with_version_check(0x0200) // one byte each major/minor vers and tell people to use the macro. Ugly, maybe, but not tough. :-) >> >> Well~I modified the include path and it's done. >> Thanks all! > > If you use `guile-config compile` (and `guile-config link`) in your Makefile > it will come out right. Unless you're also using some other "foo-config" script for the same object file (defining Guile wrappers for the Foo API?), and that one is installed in /usr/local where the old version of Guile is, you don't get the command-line order right for your specific installation quirks, etc. I don't think there is a good answer to guarantee consistent versions; some additional technique to check for consistency doesn't seem like a horrible idea, though most packages I've worked with just seem to make do with the assumption that you'll figure out how to get this right if you're installing multiple versions. Ken
