re: [Thread] The last step
On Friday 01 October 2004 15:32, "Aleksey Gurtovoy" <agurtovoy@meta-comm.com> wrote:
You can probably guess what I'm about to ask -- can we do something about Intel 8.0/Linux failures? Looking at the output below (from http://tinyurl.com/6mnzn), it seems to me that the test was attempted to be linked against *both* GCC and Intel runtimes:
I think the problem is that the compiler is running on a platform where the version of glibc is unsupported (too recent). I have come across the same problem myself. After much research I found the only workaround was to rename strol in the compilers libcprts.a This is a big hack but gets things compiling. I have a already manipulated libcprts.a but it is 1M. I can post it to whoever needs it however. Michael
Michael Stevens writes:
On Friday 01 October 2004 15:32, "Aleksey Gurtovoy" <agurtovoy@meta-comm.com> wrote:
You can probably guess what I'm about to ask -- can we do something about Intel 8.0/Linux failures? Looking at the output below (from http://tinyurl.com/6mnzn), it seems to me that the test was attempted to be linked against *both* GCC and Intel runtimes:
I think the problem is that the compiler is running on a platform where the version of glibc is unsupported (too recent). I have come across the same problem myself. After much research I found the only workaround was to rename strol in the compilers libcprts.a This is a big hack but gets things compiling. I have a already manipulated libcprts.a but it is 1M. I can post it to whoever needs it however.
Martin, should we go down this route, or should I mark up the failures as expected with a corresponding note? -- Aleksey Gurtovoy MetaCommunications Engineering
Aleksey Gurtovoy wrote:
Michael Stevens writes:
[...]
I think the problem is that the compiler is running on a platform where the version of glibc is unsupported (too recent). I have come across the same problem myself. After much research I found the only workaround was to rename strol in the compilers libcprts.a This is a big hack but gets things compiling. I have a already manipulated libcprts.a but it is 1M. I can post it to whoever needs it however.
Martin, should we go down this route, or should I mark up the failures as expected with a corresponding note?
That would work for the sake of the tests. However, this is an extremely ugly hack, and it would give a user the impression Boost would work without a problem on that platform while this is not entirely true. The only option I see would be to run two separate toolsets, one of them with the hack, the other one without it, and to markup accordingly. However, this puts more burden on the those who run the intel 8 tests (like me :o) and I'm not sure this is worth the effort. To me, it looks like this is Intel's problem and we should clearly mark it so. Of what use is a compiler for a platform that only supports rather outdated environments? Frankly, I'm quite annoyed by the number of problems we get with respect to compatibility of the intel compiler. Even more so when I see it advertised as being compatible. We're facing an incompatibility regarding to strtol() here!! I hope this problem will go away with 8.1 (which I still have to install). In short: I think we should mark up the failures as expected. Regards, m
participants (3)
-
Aleksey Gurtovoy -
Martin Wille -
Michael Stevens