Dan Stromberg <[EMAIL PROTECTED]> writes:
> I was fine with building the library with g++, but the researcher really
> wants it built with xlC_r, because he believes (and is probably right)
> that xlC_r will produce faster code, and produce a library that can be
> linked with either xlC* or g++, while a library compiled with g++ would
> appear to be only linkable, on this platform, with g++.
C++ code compiled by different compilers is almost never
link-compatible. The library compiled with xlC* will *not* be
usable by code compiled by g++ (unless the library exports a "pure C"
interface, or course).
> xlC_r -qlanglvl=extended -q64 /usr/local/lib/libmalloc.a -DHAVE_CONFIG_H -I.
> -I. -I. -I. -I./gl -I/usr/local/include -I/usr/local/include/libxml2 -I./GNU
> -g -c -M RValue.cc -DPIC -o .libs/RValue.o
The command line above is bogus:
- you are doing compilation only (the '-c' flag), therefore
libmalloc.a is out of place here.
- if you were doing the linking, the position of libmalloc.a at
the beginning of the command line is wrong. You may wish to read this:
http://webpages.charter.net/ppluzhnikov/linker.html
if you want to understand why.
> "RValue.cc", line 176.39: 1540-0016 (S) The expression must be an integral
> constant expression.
> gmake[2]: *** [RValue.lo] Error 1
>
> BaseType **argv = new (BaseType *[argc + 1]);
That code isn't portable even to g++. Here is what g++4.0.0 says about it:
junk.cc:4: error: array bound forbidden after parenthesized type-id
junk.cc:4: note: try removing the parentheses around the type-id
Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.
_______________________________________________
Help-gplusplus mailing list
Help-gplusplus@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gplusplus
