lilypond-devel
[Top][All Lists]
Advanced

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

Re: probable guile-1.8.9 release


From: Jonas Hahnfeld
Subject: Re: probable guile-1.8.9 release
Date: Sat, 16 Jan 2021 14:52:42 +0100
User-agent: Evolution 3.38.2

Am Samstag, dem 16.01.2021 um 13:38 +0100 schrieb Han-Wen Nienhuys:
> On Sat, Jan 16, 2021 at 9:56 AM Jonas Hahnfeld via Discussions on
> LilyPond development <lilypond-devel@gnu.org> wrote:
> > 
> > Am Montag, dem 11.01.2021 um 11:06 +0100 schrieb Michael Käppler:
> > > Am 11.01.2021 um 10:58 schrieb Thomas Morley:
> > > > Hi,
> > > > 
> > > > please have a look at
> > > > https://lists.gnu.org/archive/html/guile-user/2021-01/msg00026.html
> > > > 
> > > > Cheers,
> > > >    Harm
> > > > 
> > > Could this probably include Han-Wen's recent fix regarding GC?
> > 
> > My understanding is that the fix is ABI incompatible with earlier
> > releases of Guile 1.8; at least I get
> > $ LD_LIBRARY_PATH=/code/guile/install/lib/ ./out/bin/lilypond -dhelp
> > ./out/bin/lilypond: Symbol `scm_i_master_freelist2' has different size in 
> > shared object, consider re-linking
> > ./out/bin/lilypond: Symbol `scm_i_master_freelist' has different size in 
> > shared object, consider re-linking
> > 
> > This is because scm_t_cell_type_statistics, the type of the two
> > symbols, changed size (got bigger), and this is usually a no-no for a
> > minor bugfix release. I'm not saying this makes sense (AFAICT these
> > symbols shouldn't be public), but it's the current situation and the
> > bugfix would require relinking all objects depending on the library.
> 
> I can probably trim down the fix to be more backward compatible.
> 
> Do you know of documentation that details what is and is not allowed
> in an ABI-compatible change?

No, but let me know if you find one, would be good to have a reference
to a writeup from somebody who knows.

My understanding is the following:
 * API compatibility means that the same source code is expected to
work, ie no removed functions or changed semantics of arguments. Added
functions are mostly fine, I think, as are changes to public data
structures such as adding or reordering symbols. The latter requires
recompilation and / or relinking.
 * On top of that, ABI compatibility means that the library can be used
as a drop-in replacement. This means all data structures and symbols
must have the same size, and I think you may only add methods to the
end of C++ classes (but I may misremember something here).

Now because Guile 1.8 is built without -fvisibility=hidden, my
understand is that *all* internal symbols are part of the public ABI.
This means you must only change the body of functions and the size of
static variables (that are local per TU). Changing the meaning of only
internally used data structures is probably ok as long as you keep the
size.

You can easily find if you did something wrong by executing a binary
compiled against an existing version of the library. If that works,
chances are that it's ABI compatible, but I'd bet there are odd corner
cases...

Jonas

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

[Prev in Thread] Current Thread [Next in Thread]