Thursday, October 27, 2005
Tip: New compilers, old kernels
I often see customers upgrading their compilers well before upgrading their kernel. This is understandable because frankly, it's a big change to upgrade your whole kernel. But changing your compiler doesn't seem like that big of a deal.
However it is actually a big deal - compilers change, and the kernel needs to change sometimes to accomodate the compiler changes. For example, a problem was reported using GHS Diab 5.0a compiler in conjunction with 4.1 . Now 4.1 is a very old release - I couldn't even find a copy in our offices here. It was originally designed for Windows NT and 98, if that tells you anything. However, some people are still out there using it. The problem reported had to do with C++ constructors not being called. Turns out there are some changes in the way Diab's compiler handles this and basically the 5.0a release is not compatibile with our 4.1 kernel release and some other older releases. In fact, the earliest kernel release that supports 5.0 diab is 4.5.2 . Also customer was trying to mix and match our supplied libraries between kernel versions - not a good idea. For now, they were able to find the old diab and get their C++ constructors working that way.
I have seen a similar thing happen with ghs compiler - ghs 4.07 has some issues with 4.5.2 kernel compile. The environment makefiles supplied by GHS are wrong, but so were ours - ours were closer to right, but still not exactly right. This one requires a couple of makefiles to be replaced down in the kernel (the fixes are available on the ose_support group site). This is another case of a customer upgrading their compiler before upgrading the kernel software.
For our own part, we should probably do a better job of testing the older compilers against newer kernel releases, up to a point. We can't be expected to support a really old compiler or tons of older compiler releases, but we should at least certify a range of compiler releases for each vendor that would work for a given kernel release. We currently certify a specific compiler release to work on a specific kernel release, and we do this for each compiler we support. But it's a one-to-one mapping, and it maybe should be one-to-many instead - the kernel is too big a piece for developers to upgrade without a lot of thought.
However it is actually a big deal - compilers change, and the kernel needs to change sometimes to accomodate the compiler changes. For example, a problem was reported using GHS Diab 5.0a compiler in conjunction with 4.1 . Now 4.1 is a very old release - I couldn't even find a copy in our offices here. It was originally designed for Windows NT and 98, if that tells you anything. However, some people are still out there using it. The problem reported had to do with C++ constructors not being called. Turns out there are some changes in the way Diab's compiler handles this and basically the 5.0a release is not compatibile with our 4.1 kernel release and some other older releases. In fact, the earliest kernel release that supports 5.0 diab is 4.5.2 . Also customer was trying to mix and match our supplied libraries between kernel versions - not a good idea. For now, they were able to find the old diab and get their C++ constructors working that way.
I have seen a similar thing happen with ghs compiler - ghs 4.07 has some issues with 4.5.2 kernel compile. The environment makefiles supplied by GHS are wrong, but so were ours - ours were closer to right, but still not exactly right. This one requires a couple of makefiles to be replaced down in the kernel (the fixes are available on the ose_support group site). This is another case of a customer upgrading their compiler before upgrading the kernel software.
For our own part, we should probably do a better job of testing the older compilers against newer kernel releases, up to a point. We can't be expected to support a really old compiler or tons of older compiler releases, but we should at least certify a range of compiler releases for each vendor that would work for a given kernel release. We currently certify a specific compiler release to work on a specific kernel release, and we do this for each compiler we support. But it's a one-to-one mapping, and it maybe should be one-to-many instead - the kernel is too big a piece for developers to upgrade without a lot of thought.
free invisible web counter
