Re: the mangling of ‘va_list’ has changed in GCC 4.4
On Wed, Jan 27, 2010 at 11:19:35PM +0200, Modestas Vainius wrote:
> Hello,
>
> On trečiadienis 27 Sausis 2010 22:47:55 Riku Voipio wrote:
> > There is a major problem with gcc 4.4 and armel - the ABI of va_list
> > changed (for c++ libraries). We need to decide one of the following:
> >
> > 1) library package name rename (like c2a rename previously)
> >
> > + "the right thing to do"
> > + partial upgrades work as expected
> > - Some hassle for !armel sid users while transition happens
> > - Quite a bit of extra work for many unrelated people (maintainers,
> > ftp-masters..)
> >
> > 2) binNMU campaign
> >
> > - during the upgrade armel sid users packages will be broken (some
> > already are)
> > - even after, partial upgrades for armel users risk broken setups
> > + does not disturb !armel users
> > + no extra work for others but porters and release team
> >
> > 3) g++ downgrade or reverting to the old va_list mangling within g++4.4
> > for armel
> >
> > - A bunch of libraries and binaries have already been compiled with the
> > new g++
> > - I think this is a bad idea anyway
> >
> > What way should we proceed? The list of supposedly affected packages
> > follow (haven't had time to check myself).
>
> 4) it is also possible to manually create aliases that are mangled in the old
> way (va_list as void*) next to the symbols which g++-4.4 will auto-generate.
> This means some work for the maintainers (and porters) of the directly
> affected library packages (fortunately, the list of which does not seem to be
> huge). However, we win:
>
> 1) no painful transitions or disturbance on any arch including armel (i.e. it
> won't be worse than it is now);
> 2) no massive binNMUs of rdeps;
> 3) less work for the release team except tracking how affected libraries are
> being fixed;
> 4) no extra work for other teams.
Interesting. Do you have a example on howto do that?
Reply to: