[GiNaC-devel] GiNaC-1.2.3 and nestedsums-1.4.5 on Mac OS X

[Gregory Wright]

Hi,

Since Bruno Haible posted his patches to cln-1.1.8, it's built cleanly
on Mac OS X, and allowed me to build GiNaC-1.2.3. On my machine,
an 800 MHz tiBook running OS X 10.3.5, and using g++ 3.3 from Xcode 1.5,
it passes all the tests in 'make check'.

When I try to build nestedsums-1.4.5, I get build failures caused by the
inability to adjust pointers in convariant returns:


make  all-recursive
Making all in nestedsums
if /bin/sh ../libtool --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I.. 
-I/opt/local/include -I/opt/local/include -I/opt/local/include 
-I/opt/local/include    -g -O2 -MT root_of_unity.lo -MD -MP -MF 
".deps/root_of_unity.Tpo" -c -o root_of_unity.lo root_of_unity.cc; \
then mv -f ".deps/root_of_unity.Tpo" ".deps/root_of_unity.Plo"; else rm 
-f ".deps/root_of_unity.Tpo"; exit 1; fi
  g++ -DHAVE_CONFIG_H -I. -I. -I.. -I/opt/local/include 
-I/opt/local/include -I/opt/local/include -I/opt/local/include -g -O2 
-MT root_of_unity.lo -MD -MP -MF .deps/root_of_unity.Tpo -c 
root_of_unity.cc  -fno-common -DPIC -o .libs/root_of_unity.o
Euler_Zagier_sum.h:48: sorry, unimplemented: adjusting pointers for 
covariant
    returns
Euler_Zagier_sum.h:48: sorry, unimplemented: adjusting pointers for 
covariant
    returns
harmonic_sum.h:49: sorry, unimplemented: adjusting pointers for 
covariant
    returns
harmonic_sum.h:49: sorry, unimplemented: adjusting pointers for 
covariant
    returns
multiple_polylog.h:54: sorry, unimplemented: adjusting pointers for 
covariant
    returns
multiple_polylog.h:54: sorry, unimplemented: adjusting pointers for 
covariant
    returns
harmonic_polylog.h:50: sorry, unimplemented: adjusting pointers for 
covariant
    returns


(There are more header files that it complains about; I can send the 
full output if
you wish.)

I emailed Stefan Weinzierl and he pointed out that this comes from the 
macros

  GINAC_DECLARE_REGISTERED_CLASS
and
  GINAC_IMPLEMENT_REGISTERED_CLASS

Two questions:

1. Is there a workaround for this? (Since I am trying to port 
xloops/nestedsums/GiNac/cln
to the darwinports system, I would prefer no to have to add build 
another g++ compiler.
I could, if absolutely necessary, do that.)

2. Why does this happen for the nestedsums library and not for GiNaC? 
Does GiNaC
allow covariant returns but not actually use them?

Any help is appreciated.

Best Wishes,
Greg

Gregory Wright
Antiope Associates
gwright at antiope.com