Is -print-multiarch option being upstreamed?

stros in the future)? Or rather what's the status of multiarch upstreaming in general? I'm asking because cmake should probably use this one when available rather than extract the triplet with regex from the library path (which is somewhat error prone). -- Modestas Vainius sig

Re: Bug#618932: cmake multiarch support

Hello, On sekmadienis 29 Gegužė 2011 05:51:58 Steve M. Robbins wrote: > On Sat, Mar 19, 2011 at 08:29:30PM +0200, Modestas Vainius wrote: > > On ??e??tadienis 19 Kovas 2011 19:37:53 Jonathan Riddell wrote: > > > This patch adds support for multiarch library directories to cma

Bug#618748: gcc-4.5: Use insane amount of memory

nd fixed upstream. See above. -- Modestas Vainius signature.asc Description: This is a digitally signed message part.

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

er may only drop the alias when changing the name of the affected library package (most likely due to soname change). This step is not related to squeeze release. -- Modestas Vainius signature.asc Description: This is a digitally signed message part.

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

bler/symver.html 2. http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/gnu- linker/version.html -- Modestas Vainius signature.asc Description: This is a digitally signed message part.

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

o 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. -- Modestas Vainius signature.asc Description: This is a digitally signed message part.

Re: C++ symbol mangling difference between arches

Hello, On 2009 m. June 26 d., Friday 23:01:54 Florian Weimer wrote: > * Modestas Vainius: > > While apparently, VT can't be implemented differently (except \d+), > > what about size_t etc. then? They all can be implemented as regexps > > too the most simple being '

Re: C++ symbol mangling difference between arches

^_ZTvn?\d+_n?\d+ ^_ZTC - AKA construction vtable, but it is rather complex to detect where the offset is in this one, e.g.: _ZTCN6KParts15DockMainWindow3E56_NS_8PartBaseE ^^ Raphael, should I provide a patch for regexp support + {vt} subst as implic

Re: C++ symbol mangling difference between arches

ented > independently. There is definitely no need to support such cases via substitutions because they are rare and arch specific symbols look like a perfect workaround (solution?). Also dpkg-gensymbols is never going to add substitutions (or any other symbol tags), this will solely be responsibility of the maintainer or some external tool. -- Modestas Vainius signature.asc Description: This is a digitally signed message part.