[GiNaC-list] Problems

David Fang fang at csl.cornell.edu
Tue Jan 30 04:58:14 CET 2007

> i want to use ginac as a lib under Mac OS X 10.4..8. I compiled cln
> 1.1.13 without problems.
> But compiling ginac 1.3.6 gave me the well known ginsh_parser.yy error:
> if g++ -DHAVE_CONFIG_H -I. -I. -I.. -I./../ginac -I../ginac -
> DIN_GINAC  -I/usr/local/include  -g -O2 -MT ginsh_parser.o -MD -MP -
> MF ".deps/ginsh_parser.Tpo" -c -o ginsh_parser.o ginsh_parser.cc; \
> then mv -f ".deps/ginsh_parser.Tpo" ".deps/ginsh_parser.Po"; else rm -
> f ".deps/ginsh_parser.Tpo"; exit 1; fi
> ginsh_parser.yy:50:6: error: missing binary operator before token
> "wrapper"
> ginsh_parser.yy:56:6: error: missing binary operator before token
> "wrapper"
> ginsh_parser.yy:860:6: error: missing binary operator before token
> "wrapper"
> ginsh_parser.yy:870:6: error: missing binary operator before token
> "wrapper"
> ginsh_parser.yy:922:6: error: missing binary operator before token
> "wrapper"
> ginsh_parser.yy: In function 'char** fcn_completion(const char*, int,
> int)':
> ginsh_parser.yy:859: error: invalid conversion from 'const char*' to
> 'char*'
> ginsh_parser.yy:869: error: invalid conversion from 'const char*' to
> 'char*'
> make[2]: *** [ginsh_parser.o] Error 1
> make[1]: *** [all-recursive] Error 1
> make: *** [all] Error 2

	I just build cln-1.1.13, ginac-1.3.6 myself (OS X 10.4, dual G4)
without problems, and bison didn't even play a role because ginac ships
the resulting .cc sources with it (pre-built using bison 1.875, it seems).
The only reason I can imagine why your build tried to run bison is if the
timestamps were somehow not preserved upon unpacking, or you accidentally
touched the yacc source.  In the case of a timestamp problem can you try
"touch ginsh/*.{h,cc}" to avoid re-running bison?

> I'm using gcc --version
> i686-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build
> 5363)
> Copyright (C) 2005 Free Software Foundation, Inc.
> and yacc --version
> bison (GNU Bison) 2.3
> Written by Robert Corbett and Richard Stallman.

For comparison, my gcc:

Using built-in specs.
Target: powerpc-apple-darwin8
Configured with: /private/var/tmp/gcc/gcc-5363.obj~28/src/configure
--disable-checking -enable-werror --prefix=/usr --mandir=/share/man
--with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib
--build=powerpc-apple-darwin8 --host=powerpc-apple-darwin8
Thread model: posix
gcc version 4.0.1 (Apple Computer, Inc. build 5363)

> Is there another thing i have to instal? O shold i use a different
> version of gcc/Yacc?

	Just for kicks, I 'touched' the yacc file to force a rebuild using
our version of bison, 2.3, and it still rebuilt fine for me.  Can you give
some more context on the failure?  For example, what did your configure
report about 'readline', since the line numbers referenced in your report
are all related to readline configuration and the resulting preprocessor
macros.  (I'm using readline-5.0).  You can find some _RL_ results in
"config.h" too.  Just a stab in the dark, does the problem go away if you
wrap those conditionals in one more pair of enclosing parentheses?

	Speaking of fink, anyone on this list consider submitting a
package for cln/ginac?  They are much easier to build than they were a few
years ago, thanks to various libtool and configury updates.


David Fang
Computer Systems Laboratory
Electrical & Computer Engineering
Cornell University
	-- (2400 baud? Netscape 3.0?? lynx??? No problem!)

More information about the GiNaC-list mailing list