On 18/05/10 17:33, Johannes Schmid wrote:
Hi!
The ultimate goal is being able to automatically detect at link time
that program A requires library B implementing at least version X of
the interface and embedding such information in packages
automatically. Just like we do for glibc with its GLIB
Le samedi 22 mai 2010 à 18:35 +0200, Patryk Zawadzki a écrit :
> What deb-based distros do now is a workaround, basically doing the
> same thing from the other end. Having symbol versions upstream would
> remove the necessity of doing the mapping manually.
Happily it’s mostly automated, otherwise
On Sat, May 22, 2010 at 6:11 PM, Josselin Mouette wrote:
> Le mardi 18 mai 2010 à 12:32 -0400, Behdad Esfahbod a écrit :
>> > As for not wanting to use versioned symbols, could you provide more
>> > information why such a decision was made?
>>
>> I can't speak for Matthias, but I guess it's becaus
On Sun, 2010-05-23 at 01:11 +0900, Josselin Mouette wrote:
> Le mardi 18 mai 2010 à 12:32 -0400, Behdad Esfahbod a écrit :
> > > As for not wanting to use versioned symbols, could you provide
> more
> > > information why such a decision was made?
> >
> > I can't speak for Matthias, but I guess it'
Le mardi 18 mai 2010 à 12:32 -0400, Behdad Esfahbod a écrit :
> > As for not wanting to use versioned symbols, could you provide more
> > information why such a decision was made?
>
> I can't speak for Matthias, but I guess it's because no one pointed out what
> currently-existing problem exactly
On Tue, 2010-05-18 at 17:24 +0200, Patryk Zawadzki wrote:
> Today Elan Ruusamäe and me spent some time making glibc compile with
> versioned interfaces for exported symbols.
>
> The ultimate goal is being able to automatically detect at link time
> that program A requires library B implementing at
On 05/18/2010 01:43 PM, Matthias Clasen wrote:
> On Tue, May 18, 2010 at 12:58 PM, Behdad Esfahbod
> wrote:
>
>> If we autogenerate the version script, I think Matthias can be bribed into
>> accepting it
>
> Well, the arguments against symbol versioning have not really changed
> since ca 2005, s
On Wed, May 19, 2010 at 11:05 AM, Alexander Larsson 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 fo
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 droppin
On Tue, May 18, 2010 at 9:33 PM, Matthias Clasen
wrote:
> On Tue, May 18, 2010 at 2:30 PM, Patryk Zawadzki wrote:
>
>>
>>> Well, the arguments against symbol versioning have not really changed
>>> since ca 2005, so we do we need to discuss this again ?
>>
>> Please kindly point me to a list of ar
On Tue, May 18, 2010 at 2:30 PM, Patryk Zawadzki wrote:
>
>> Well, the arguments against symbol versioning have not really changed
>> since ca 2005, so we do we need to discuss this again ?
>
> Please kindly point me to a list of arguments as I was not a
> participant in that discussion.
>
I don
On 18/05/10 18:50, Patryk Zawadzki wrote:
> The most important to us as a distribution is being able to
> automatically maintain dependencies for libraries that add symbols
> without changing their soname. For example g_malloc_n was introduced
> in glib 2.24.
>
> We currently need to manually test
On Tue, May 18, 2010 at 7:43 PM, Matthias Clasen
wrote:
> On Tue, May 18, 2010 at 12:58 PM, Behdad Esfahbod
> wrote:
>
>> If we autogenerate the version script, I think Matthias can be bribed into
>> accepting it
>
> Well, the arguments against symbol versioning have not really changed
> since ca
On Tue, May 18, 2010 at 12:58 PM, Behdad Esfahbod
wrote:
> If we autogenerate the version script, I think Matthias can be bribed into
> accepting it
Well, the arguments against symbol versioning have not really changed
since ca 2005, so we do we need to discuss this again ?
- It doesn't really
On 05/18/2010 12:50 PM, Patryk Zawadzki wrote:
> On Tue, May 18, 2010 at 6:32 PM, Behdad Esfahbod
> wrote:
>> On 05/18/2010 12:30 PM, Patryk Zawadzki wrote:
>>> As for not wanting to use versioned symbols, could you provide more
>>> information why such a decision was made?
>> I can't speak for Ma
On Tue, May 18, 2010 at 6:49 PM, Tristan Van Berkom wrote:
> It looks to me like your script is going to need somebody
> to maintain it in the long term (like one of those annoying
> extra files you want to shoot the GTK+ build system for, i.e.
> gtk.symbols or such).
>
> Do you have a full prop
On Tue, May 18, 2010 at 6:32 PM, Behdad Esfahbod
wrote:
> On 05/18/2010 12:30 PM, Patryk Zawadzki wrote:
>> As for not wanting to use versioned symbols, could you provide more
>> information why such a decision was made?
> I can't speak for Matthias, but I guess it's because no one pointed out wha
On Tue, May 18, 2010 at 12:30 PM, Patryk Zawadzki wrote:
> On Tue, May 18, 2010 at 6:25 PM, Behdad Esfahbod
> wrote:
>> On 05/18/2010 12:12 PM, Patryk Zawadzki wrote:
And neither are there plans to start using versioned symbols.
>>> Good news then.
>> Did you misread what Matthias said maybe
On 05/18/2010 12:30 PM, Patryk Zawadzki wrote:
> On Tue, May 18, 2010 at 6:25 PM, Behdad Esfahbod
> wrote:
>> On 05/18/2010 12:12 PM, Patryk Zawadzki wrote:
And neither are there plans to start using versioned symbols.
>>> Good news then.
>> Did you misread what Matthias said maybe?
>
> I as
On 05/18/2010 12:12 PM, Patryk Zawadzki wrote:
>> And neither are there plans to start using versioned symbols.
>
> Good news then.
Did you misread what Matthias said maybe?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gno
On Tue, May 18, 2010 at 6:25 PM, Behdad Esfahbod
wrote:
> On 05/18/2010 12:12 PM, Patryk Zawadzki wrote:
>>> And neither are there plans to start using versioned symbols.
>> Good news then.
> Did you misread what Matthias said maybe?
I assumed it was because of the possible ABI break so I pointed
On Tue, May 18, 2010 at 5:31 PM, Matthias Clasen
wrote:
> On Tue, May 18, 2010 at 11:28 AM, Colin Walters wrote:
>> On Tue, May 18, 2010 at 11:24 AM, Patryk Zawadzki
>> wrote:
>>
>>> I'd like to propose adapting versioned symbols across the stack as
>>> soon as possible. Keep in mind it'll prob
On Tue, May 18, 2010 at 5:33 PM, Johannes Schmid wrote:
> Hi!
>
>> The ultimate goal is being able to automatically detect at link time
>> that program A requires library B implementing at least version X of
>> the interface and embedding such information in packages
>> automatically. Just like we
Hi!
> The ultimate goal is being able to automatically detect at link time
> that program A requires library B implementing at least version X of
> the interface and embedding such information in packages
> automatically. Just like we do for glibc with its GLIBC_x_y
> interfaces.
>
> The changes
On Tue, May 18, 2010 at 11:28 AM, Colin Walters wrote:
> On Tue, May 18, 2010 at 11:24 AM, Patryk Zawadzki
> wrote:
>
>> I'd like to propose adapting versioned symbols across the stack as
>> soon as possible. Keep in mind it'll probably break the existing ABI -
>> didn't test that yet - so "as s
On Tue, May 18, 2010 at 11:24 AM, Patryk Zawadzki wrote:
> I'd like to propose adapting versioned symbols across the stack as
> soon as possible. Keep in mind it'll probably break the existing ABI -
> didn't test that yet - so "as soon as possible" might mean "during the
> nearest ABI break".
Th
Today Elan Ruusamäe and me spent some time making glibc compile with
versioned interfaces for exported symbols.
The ultimate goal is being able to automatically detect at link time
that program A requires library B implementing at least version X of
the interface and embedding such information in
27 matches
Mail list logo
