> Kristofer Wempa <wempa@xxxxxxx> writes: > > > I am looking to build an entire set of tools using GCC 4.5 for SLES10, > > which is based on GCC 4.1.2. According to the GCC 4.4 release notes, > > there is an ABI change that causes it to be incompatible with earlier > > GCC versions. My initial plan was to build GCC 4.5 and then build the > > remaining software with 4.5 using the .-fabi-version. option to make > > it generate binaries compatible with GCC 4.1.2. However, the GCC man > > page and other documentation I have come across says that GCC 4.4 and > > 4.5 still using version 2.0 of the ABI, which was introduced in GCC > > 3.4. Now, I.m confused. If GCC 4.4 introduces an ABI change, then > > how can it still be the same ABI version as the earlier GCC versions ? > > It sounds almost like there is a minor change to the ABI, but that > > they still want to consider it compatible with the previous ABI > > version. Can somebody please clarify this for me ? I have bounced > > this off of a couple of other people who are familiar with these > > concepts and they also agree that it.s unclear. Any help would be > > greatly appreciated. > > The issue is unfortunately more complex than it should be. The > -fabi-version option is not well named. As the documentation states, it > refers only to the C++ ABI. The documentation is also clear that the > default value is 2, and describes the changes in later versions. This > is for C++ only. > > gcc 4.4 made two ABI changes that apply to all language, not just C++. > > The first affects all targets: structs with the packed attribute which > contained bitfields of type char were changed to avoid introducing > incorrect padding. If your code does not such a struct, nothing has > changed. Note that this is an unusual case in two respects: you have to > explicitly use __attribute__ ((packed)), and you have to use bitfields > of type char. > > The second ABI change is specific to x86_64. The way in which certain > types of structs are passed to a function or returned from a function > has changed. The structs in question are 1) structs with a flexible > array member; 2) structs with a complex float member; 3) unions with a > long double member. This change only affects code which actually passes > a struct to a function, rather than, say, a pointer to a struct. This > change was made to conform to the public x86_64 ABI. > > For both ABI changes, gcc 4.4 and later will print a message if your > code uses the construct. This note be disabled via > -Wno-packed-bitfield-compat for the first change and -Wno-abi for the > second change. This is only a note, not a warning or an error. > > So, you should simply use the compiler as usual, but watch for > occurrences of that note, perhaps in a script. If you don't see the > note, you are fine. > > There is no way to tell gcc 4.4 and later to use the earlier ABI. The > earlier ABI was buggy. I'm not sure I agree with this decision, but it > is what the gcc maintainers decided. > Thanks. That does clarify a few things. However, I'm not worried about the packages I build with GCC 4.5.1 using any of those constructs. I'm worried about any of the existing system libraries that are linked by the packages I build. We define a set of system packages to be a "base system". That includes the kernel, the basic commands and a number of low-level libraries (for example, libz). We build our tool chains on top of that base system. Any of these libraries that are part of our "base system" are built with GCC 4.1.2. I can't just assume that all of these system libraries didn't use any of those constructs where the ABI changed. Will there be a potential problem if the packages I build with GCC 4.5.1 link against system libraries that used these constructs ? Or, would I have completely build everything (including those base system libraries) from scratch with GCC 4.5.1 ?
