On Thu, Sep 23, 2004 at 01:09:38PM -0400, Andy Dougherty wrote:
> On Wed, 22 Sep 2004, William Coleda wrote:
>
> > Attached, find a patch that does a first pass of this.
> [ . . . ]
>
> > # OTHER FILE GROUPS:
> > @@ -412,6 +440,9 @@
> > .c$(O) :
> > @$(PERL) tools/dev/cc_flags.pl ./CFLAGS $(CC) "" $(CFLAGS) -I$(@D)
> > ${cc_o_out}$@ -c $<
> > +%.pbc:%.imc
> > + @.${slash}$(TEST_PROG) -o $@ $<
> > +
>
> Is there any important reason for the leading '@' there?
Nope. Just copying the @ from the line above. Whoever applies the patch,
that can be removed.
> When I tried
> this patch, the result was the following (split to fix up the long
> lines, and yes, all those mostly-useless -L options are doubled for
> some unknown reason)
> src/nci_test.c
> cc -G -L/usr/lib -L/usr/ccs/lib -L/opt/SUNWspro/SC4.2/lib -L/usr/local/lib \
> -L/usr/lib -L/usr/ccs/lib -L/opt/SUNWspro/SC4.2/lib -L/usr/local/lib \
> -o runtime/parrot/dynext/libnci.so src/nci_test.o
> GNUmake: *** [runtime/parrot/library/libpcre.pbc] Segmentation Fault (core
> dumped)
I suspect that, just like I had issues with certain files in the library
on my platform, you're having issues with the library on your platform. Can
you comment out the line that adds libprce.pbc to the Makefile and see if
there are any others that give trouble? If so, the author of that particular
library module should take a look, methinks.
> More generally, I think the build process should generally avoid hiding
> what's going on until we're *sure* that it works correctly nearly
> everywhere, so while you're in that section of root.in, you probably ought
> to remove the '@' before the preceeding rule as well.
Good idea.
