the Compiler crashes when both flags are given together:
-qobjmodel=ibm -qeh
not matter if -g or -O2
with XLC/C++ 7.0 with Jun09 fixpack.
<http://mxr.mozilla.org/mozilla1.9.1/source/content/html/content/src/nsHTMLLinkElement.cpp>
xlC_r -qlanglvl=extended -qobjmodel=ibm -qeh -o nsHTMLLinkElement.o -c ...
xlC_r: 1501-224 fatal error in /usr/vacpp/exe/xlCentry: signal 11 received
gmake[6]: *** [nsHTMLLinkElement.o] Error 251
The same crash happens using xlC_r v6, v7 and v8 each with latest fixes.
The source file only has about 500 lines, but that's quite meaningless
for C++.
Workaround 1: compilation the whole app with default -qobjmodel=compat
(compiling without -qeh compiles and links.)
The compiles docs don't say anything about an interdependency between
these two parameters.
No support contract for hobbyist no-fee opensource projects affordable :-(
Any better workaround?
--
Uli Link
from http://www-01.ibm.com/support/docview.wss?uid=swg27005414&aid=1
xlc v7
....
Exception-handling is enabled. If -qeh is specified without any
suboption, -qeh=v5 is assumed.
Thus i would try suboption -qeh=v6 for the vacpp 6 or 7 compiler
where for xlc v10 the default for -qeh is set to v6
hth
Hajo
> ....
> Exception-handling is enabled. If -qeh is specified without any
> suboption, -qeh=v5 is assumed.
>
> Thus i would try suboption -qeh=v6 for the vacpp 6 or 7 compiler
Have tried with -qeh=v6 too
Together with -qobjmodel=ibm the internal compiler error appears.
omitting one flag of those two will compile. Firefox 3 and later make
extensive usage of C++ exceptions, so I think omitting -qeh is bad idea.
-qeh(=v5) is the default for XLC/C++ 8.
--
ULi