On Sun, 5 Dec 2004, Jarkko Hietaniemi wrote:
> I am pretty certain that parrot was building fine in Tru64 back in
> 2004/11/07 15:12:42 when I submitted a patch (directly to CVS)
> for jit/alpha/jit_emit.h to get alpha JITing to compile at all.
>
> Since then something has broken building parrot in Tru64. What happens
> is that dynclasses/build.pl attempts something called a "partial
> link" for the various Python-related objects, and the attempt fails
> because it tries to invoke "ld" with parameters meant exclusively for
> the native "cc" (or the C++ compiler "cxx"):
>
> ld -std -D_INTRINSICS -fprm d -ieee -I/p/include -DLANGUAGE_C -pthread
> -g -DHAS_JIT -DALPHA -L/p/lib -shared -expect_unresolved "*" -O4
> -msym -std -s -L/p/lib ../src/extend.o -o python_group.so
> lib-python_group.o pybuiltin.o pyobject.o pyboolean.o pyclass.o
> pycomplex.o pydict.o pyfloat.o pyfunc.o pygen.o pyint.o pylist.o
> pylong.o pymodule.o pynone.o pytype.o pystring.o pytuple.o
> ld: Badly formed hex number: -fprm
> ld: Usage: ld [options] file [...]
> partial link python_group.so failed (256)
>
> If "ld" in the above is replaced with "cc", things work fine.
The offending line in config/gen/makefiles/dynclasses_pl.in
is probably this one:
$LD $CFLAGS $LDFLAGS $LD_LOAD_FLAGS $LIBPARROT
That CFLAGS doesn't belong there. CFLAGS are intended to be sent to $CC,
not to $LD. The command being called here is $LD, which is defined in
config/init/data.pl as the "Tool used to build shared libraries and
dynamically loadable modules."
I no longer remember why LD is set to 'ld' on Tru64 -- is it just Ultrix
heritage combined with lots of inertia or is it really a sensible setting?
In any case, dynclasses_pl.in is wrong. There should be no CFLAGS there.
--
Andy Dougherty [EMAIL PROTECTED]
