[perl #32877] parrot build broken in Tru64, cc/ld confusion

[Jarkko Hietaniemi]

# New Ticket Created by Jarkko Hietaniemi
# Please include the string: [perl #32877]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=32877 >

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.

I don't know where to start fixing this since the
config/init/hints/dec_osf.pl hasn't change since April,
and the config/gen/makefiles/dynclasses_pl.in (which is
the source of dynclasses/build.pl, which is the one that
issues the mistaken "ld" command) hasn't change since 2004/11/07
in any obvious ways.

--
Jarkko Hietaniemi <j...@iki.fi> http://www.iki.fi/jhi/ "There is this special
biologist word we use for 'stable'. It is 'dead'." -- Jack Cohen

[Andrew Dougherty]

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 doug...@lafayette.edu

[Sam Ruby]

Andrew Dougherty wrote:
>
> 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 can't find anything that fails if this is removed, so I committed the
change.

- Sam Ruby

[Jarkko Hietaniemi]

>
> 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?

Could well be Ultrix heritage, but in any case the parameter syntaxes of
Tru64 cc and ld are rather different and non-intersecting, and the cc
doesn't automatically pass through unknown parameters to ld (one needs
to use the -W for explicit passing.)

The cc and ld manpages for example here (blame HP for the awful URLs):
http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/V51B_HTML/MAN/MAN1/0607____.HTM
http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/V51B_HTML/MAN/MAN1/0668____.HTM

> In any case, dynclasses_pl.in is wrong. There should be no CFLAGS there.

--

[Jarkko Hietaniemi]

Sam Ruby via RT wrote:

> Andrew Dougherty wrote:
>
>>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 can't find anything that fails if this is removed, so I committed the
> change.

Thanks, that helped!

> - Sam Ruby