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

Re: i386 compatibility & libstdc++

Hash: SHA1

On Friday 25 April 2003 19:31, Matt Zimmerman wrote:
> On Fri, Apr 25, 2003 at 05:06:00PM +0200, Arnd Bergmann wrote:

> > No, the only thing that is enforced is that i386 systems cannot use the
> > i486+ ABI. It is a very possible solution to have use the i386 ABI on any
> > system and the i486+ ABI only on i686+.
> That sounds contrary to what Matthias originally said:
> > > - Trying to "fix" this resulted in libstdc++5 packages built for
> > >   i386 and ix86, and selecting the atomicity implementation based on
> > >   target cpu macros. This approach doesn't work, as I learned now.
> > >   See http://gcc.gnu.org/ml/libstdc++/2003-04/msg00394.html: It's
> > >   not possible to mix the two implementations.

The point here is that you cannot mix the atomicity variants within one
binary. It could however work if you also have two conflicting libstdc++5
packages, with different sonames. The consequence of this is that every
package using libstdc++ needs to be built twice, i.e. with the both ABI
To make this work properly, dpkg and the other package tools will first
have to understand the whole truth about i386/i486/i686/amd64 architecture
names, as it has been discussed before. We need this feature anyway for 
new 64 bit (sub-)archs like amd64.

> Though, buying a new i486 isn't as unusual as you might think.
http://old.picogui.org/wiki/view/Main/ArndBergmann ;-)
Guess what CPU the DIL/NetPC is using. I was not arguing for removing
support for i486 systems. Binaries compiled with '-march=i386' even
tend to run better on i486 systems than binaries compiled with '-march=i486
- -mcpu=i686', because i386 executables are significantly smaller and
i486 systems are often short of RAM. So, making the split at i686 won't
hurt i486 users that continue to use i386 binaries.

	Arnd <><
Version: GnuPG v1.2.1 (GNU/Linux)


Reply to: