Re: Versioned symbols for 3.0?
- From: Patryk Zawadzki <patrys pld-linux org>
- To: Alexander Larsson <alexl redhat com>
- Cc: Behdad Esfahbod <behdad esfahbod gmail com>, desktop-devel-list <desktop-devel-list gnome org>, Colin Walters <walters verbum org>
- Subject: Re: Versioned symbols for 3.0?
- Date: Wed, 19 May 2010 14:16:57 +0200
On Wed, May 19, 2010 at 11:05 AM, Alexander Larsson <alexl redhat com> wrote:
> On Tue, 2010-05-18 at 20:30 +0200, Patryk Zawadzki wrote:
>> > - It can only version functions, we still have have unversioned types,
>> > properties, signals, etc, etc.
>> It's only able to version exported symbols and I wouldn't ask for
>> anything more than that. I didn't mean to propose dropping the API
>> documentation, just making our lives a little easier.
> That makes it useless though. If an app uses a new signal but not a new
> symbol then symbol versioning won't detect that a new glib is needed, so
> you can't trust it anyway.
> Also, many times apps rely on e.g. a newer version of glib fixing an
> issue with a function. That doesn't make the function "new" so it won't
> get a new version (typically), so again the symbol versioning isn't
The problem we encountered recently is that glib itself introduces new
symbols to binaries compiled with 2.24.
That is compiling an older application with 2.24 causes it to depend
on new symbols introduced in 2.24. For example the g_malloc_n.
Also, IMHO stating that introducing an _additional_ safeguard does not
solve 100% cases does not render the safeguard useless.
] [Thread Prev