Re: portability thing?

[Paul Pluzhnikov]

Dan Stromberg <strombrg@dcs.nac.uci.edu> 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.