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

Re: the mangling of ‘va_list’ has changed in GCC 4.4

On 27.01.2010 23:11, Riku Voipio wrote:
On Wed, Jan 27, 2010 at 11:19:35PM +0200, Modestas Vainius wrote:

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,

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?

IMO the major work is to identify affected libraries. if this is done, you can decide if binNMUs or manual creation of aliases is the bigger pain.


Reply to: