This is a proposal for a way to handle backwards compatibility in the
face of continuing C++ compiler ABI breaks. Rationale:
- The GCC team have an explicit policy of preferring standards compliance
to ABI stability. I think there is no 100% perfect test suite for this
standard, and even if there was, it's unlikely that such a complicated
document is never open to interpretation. Likewise the C++ spec itself
evolves with time.
Consequently, it's possible (probable?) that we will be dealing with ABI
breaks into the medium term future. These need to be managed.
- It is desireable to have binary compatibility and to manage interface
breaks. This is what ELF soname versioning is all about, but in the face
of compiler breaks as opposed to library breaks, soname versioning is not
enough. A library libqt.so.3 compiled with one compiler may not export the
same interface as libqt.so.3 compiled with another, yet the user may wish
to run binaries compiled with the gcc 3.3 ABI on a 3.4 compiled system.
One of my assumptions is that the C++ standard library is parallel
installable and has a different soname for each ABI. From what I've read
about g++ ABI policy this assumption seems to be correct, please let me
know if it is not.
The proposal is to modify the dynamic linker so that when a
library which depends on a symbol version of CXXABI_X.Y is loaded, each
element in the library search path is tested once with $dirname/cxxabi-X.Y
and once with $dirname. So, if you have a version of Qt compiled with abi
1.2 (gcc 3.2,3.3), that can be placed in /usr/lib/cxxabi-1.2/libqt.so.3
and then the version compiled with the "native" ABI can be placed in
/usr/lib as per normal.
A similar technique has been used before with the LD_ASSUME_KERNEL
environment variable switching between /lib, /lib/i686, /lib/tls and so
on. This mechanism would be similar, except triggered by the CXXABI symbol
version rather than an environment variable.
This allows C++ binaries built for older versions of the system to operate
correctly on newer systems when the right compat-* packages are installed.
I propose this here as there are a good set of distro, glibc
and gcc developers working for Red Hat, so it seemed like a good place to
find people to shoot it down :)
What are peoples thoughts on this mechanism? Using CXXABI_ is somewhat
inelegant but this has the advantage that it works with the toolchains
I have a soyo kt400 dragon ultra motherboard with a hpt370/372 raid
controller. The problem is that booting kernel 2.6.6-1.435.2.3 always
ends up with an oops in init_setup_hpt366().
EIP: 0060:[<0232d6eb>] Not tainted
EFLAGS: 00010246 (2.6.6-1.435.2.3)
EIP is at init_setup_hpt366+0x61/0x139
eax: 00000006 ebx: 21e52800 ecx: 01040006 edx: 21f06f6c
esi: 00000000 edi: 022a7cab ebp: 022e0b00 esp: 21f06f84
ds: 007b es: 007b ss: 0068
Process swapper (pid: 1, threadinfo=21f06000 task=21ebf630)
Stack: 00000000 000000d0 00000006 022a7cab 022a7cab 022a8021 022a8028
022a8037 00000000 00000000 022e0ce0 21e52800 00000000 00000000
0232fe52 21e52800 00000000 0232fe8f 0233bcf4 0232fdc1 0232fe0f
Code: ac aa 84 c0 75 fa 8b 44 24 08 83 e8 03 83 f8 02 0f 86 b1 00
I can boot with kernel 2.6.5-1.358, but the file /proc/ide/hpt366 shows
garbage in the place of the chipset and the output of the hpt366
initialization code in dmesg is all messed up. I've already booted with
'pci=noacpi', 'noapic' and 'acpi=off', but had the same results with
both kernels. Any ideas?
Where can I find the equivalent to
OpenOffice1.2.0/share/uno_packages? I want to install
the postgresql-sdbc-driver. Did the openoffice get
slit out to different directories? Are different
database connection drives going to be considered for
I would like to know what is currently the "official" way for a
packager to add new MIME types and the correct corresponding
application bindings to Gnome in general, and Nautilus in particular. I
thought it was just a matter of dropping the right foo.keys and
foo.mime files into /usr/share/mime-info, but it turns out this has
pretty much zero effect on anything. Instead one has to edit the
somewhat obscure /usr/share/mime/packages/freedesktop.org.xml file and
call the update-mime-database command.
I understand this is being worked on in the next version of Gnome, but
for the time being, how is one supposed to do this from an RPM spec
[root@lembas o]# rpm -U openoffice.org-1.1.2-1.i386.rpm openoffice.org-libs-1.1.2-1.i386.rpm openoffice.org-i18n-1.1.2-1.i386.rpm
error: Failed dependencies:
libkdeui.so.4 is needed by openoffice.org-1.1.2-1
libebook.so.8 is needed by openoffice.org-libs-1.1.2-1
libedataserver.so.3 is needed by openoffice.org-libs-1.1.2-1
Why is it needed? Just curious.
The primary reason I'm asking is that I'm afraid to install kdelibs
from Rawhide. They require new libstdc++, which might not be terribly
compatible with my FC2 system.
People should be aware of a way bigger NR_GROUPS for a current
kernel if compiled against a current glibc-kernheaders.
Florian La Roche
* Fri Jul 30 2004 Arjan van de Ven <arjanv(a)redhat.com>
- update limits.h to reflect NR_GROUPS change
There is a bug in the latest OO packages. In /usr/lib/ooo-
1.1/program/setup lines 158 and 160, I believe, are commented out. This
makes the script barf because there is nothing between then and else and
else and fi. Removing the comments seems to work just fine. So why not
file a bug? Because it is too simple of a fix.
If it's there and you can see it, it's REAL If it's there and you can't
see it, it's TRANSPARENT If it's not there and you can see it, it's
VIRTUAL If it's not there and you can't see it, it's GONE! -- Unknown
On Wed, 28 Jul 2004 15:08:16 -0500
David T Farning <dfarning(a)sbcglobal.net> wrote:
> > >So they run on i386 and are .i386.rpm but i686 optimised. The packages in
> > >.i686 form are packages containing functionality that won't run on i386
> > >and are carefully chosen because it matters in those packages alone that
> > >i686 instructions can be used.
> > >
> > Sure, but what can do optimization without using the *hardcoded* cpu
> > instructions inserted in the architecture ?
> > BTW when i've some spare time, i'll try compiling an optimized version
> > of some meaningful packages and will post here the results.
> Isn't arguing with Alan Cox about kernel hacking like 
We are not arguing the kernel here, mind. It's the userland which is
built without additional instructions.
Let's see if Angelo comes with actual numbers. Various people did
benchmarks before, and it appears that the speedup is very hard to
discern among the noise. Basically, using different DIMMs gives you
more variation... But I would not be surprised if he finds an application
which does see a benefit.
Fedora Core is an excellent distro, it is complete, easy and features a
lot of packages.
I think that the only thing it misses is to release an i686 optimized
version (just like i386 and amd64). Packages compiled with that
optimization would be a lot faster, and i think that 99% of fedora users
run a i686-compatible processor:
- Intel sold starting from 1995: Pentium Pro, Pentium 2, Pentium 3,
- All AMDs
The i686 is really more powerful, it is pipelined, it features hardcoded
floating point (FPU), it can process more than 1 instruction per cycle..
but all this features are all wasted if it isn't compiled to use them.
GCC can take advantage of all the new instruction provided with i686
really well, the builds will be identical to the i386 one and you can
provide both archs in two different folders.
Just one question, why not ?
Anyway Fedora is the best distro I know.