PL/R compiles and installs ok on my OS X 10.2.4, the corresponding line is
gcc -traditional-cpp -g -O2 -Wall -Wmissing-prototypes
-Wmissing-declarations -flat_namespace -bundle -undefined suppress plr.o
pg_conversion.o pg_backend_support.o pg_userfuncs.o pg_rsupport.o -L/sw/lib
-L/sw/lib/R/bin
Adam Witney wrote:
PL/R compiles and installs ok on my OS X 10.2.4, the corresponding line is
gcc -traditional-cpp -g -O2 -Wall -Wmissing-prototypes
-Wmissing-declarations -flat_namespace -bundle -undefined suppress plr.o
pg_conversion.o pg_backend_support.o pg_userfuncs.o pg_rsupport.o -L/sw/l
Joe Conway writes:
> Below is the Makefile. The key problem is that I need to get a "bundle"
> built instead of a "dynamiclib", or so I am told.
The PostgreSQL makefiles do use "bundle". Tell the user to use the
standard distribution.
--
Peter Eisentraut [EMAIL PROTECTED]
-
Joe Conway <[EMAIL PROTECTED]> writes:
> Below is the Makefile. The key problem is that I need to get a "bundle"
> built instead of a "dynamiclib", or so I am told.
It's quite likely that the problem is in Makefile.shlib and isn't
specific to plr at all. Ask the complainant if plperl, pltcl, or
I've written PL/R to make use of the contrib build system, and modelled
its Makefile after other contrib modules. One user who tried installing
PL/R under OS X sent me this:
The makefile does
gcc -traditional-cpp -g -O2 -Wall -Wmissing-prototypes
-Wmissing-declarations -fno-common -inst
