[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Possible library versioning approach -- (evaluation requested)



Daniel Jacobowitz <dan@debian.org> writes:

> Proper management of symbol versions and a decently thought-out ABI
> mean that this problem never arises.  Consider the way glibc does it;
> yes, there are periodic problems based on the ridiculous complexity
> level, but it's kept the same SONAME and changed pretty substantially.

I may just be misunderstanding, but it seems like in the case of libc,
given its function's inputs and outputs, that's likely to be a lot
easier than it would be for guile/perl/python libraries since they're
dynamically typed.

libguile functions (and derived library functions) all pass in/out SCM
values, and a SCM value might be a guile list, vector, GOOPS object,
integer, bignum, string, etc.  I guess if libguile promised to never
change the underlying layout of all of these types, nor they way
they're allocated and garbage collected, then you might be OK, but
that seems somewhat restrictive for a developing language, and if
libguile changes anything significant, it may well affect the API of
all the libs that are built against it since they're all likely to
export SCM values.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4



Reply to: