[perl #40030] [PATCH] compiler/imcc missing dependency

[Fonseka @ Gmail . Com]

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

The trunk wasn't compilling in my machines...

After digging into Makefile I found missing depencies linking
miniparrot and parrot

Here's the patch that solved it

server parrot # diffstat imcc_dependency.diff
CREDITS | 5 +++++
config/gen/makefiles/root.in | 2 ++
2 files changed, 7 insertions(+)

--
Will work for bandwidth

[Leopold Toetsch]

Am Montag, 31. Juli 2006 22:38 schrieb fon...@gmail.com:
>
> The trunk wasn't compilling in my machines...
>
> After digging into Makefile I found missing depencies linking
> miniparrot and parrot

+ $(IMCC_DIR)/imclexer$(O) $(IMCC_DIR)/parser_util$(O)
$(IMCC_DIR)/debug$(O)

This isn't correct either. These object files are already part of libparrot
(see also IMCC_O_FILES).

There must be some other problem elsewhere.

leo

[fon...@gmail.com]

Found the problem... it was MY problem... I had rests of an old instalation
of parrot in my /usr/local/lib, and gcc was pulling libparrot from there,
making the hole process borked...

Removed the old instalation, and parrot compiles fine now :) sorry for this
wrong patch :)

leo

[Leopold Toetsch]

Am Mittwoch, 2. August 2006 19:52 schrieb fon...@gmail.com:
> > There must be some other problem elsewhere.
>
> Found the problem... it was MY problem... I had rests of an old instalation
> of parrot in my /usr/local/lib, and gcc was pulling libparrot from there,
> making the hole process borked...

Strange. I tried hard to resolve:
http://rt.perl.org/rt3//Public/Bug/Display.html?id=39742
and didn't see any bad interaction of an installed Parrot (albeit there are a
lot of such reports, that there is one).

leo

[fon...@gmail.com]

I don't really know how to solve this problem... AFAIK gcc pulls by default
libs from /usr/local/lib or /usr/lib as soon as you do -l<lib>... You can
pass -L/path to gcc, but maybe the deafult search paths has priority over
the hand-defined ones. Guess I'll have to digg it more...

[Nick Glencross]

I think that the comments in this entry are still valid.

http://rt.perl.org/rt3/Public/Bug/Display.html?id=38217#txn-128692

There's was also a stab at a patch in r11320, but I botched it (in the
embedded interface) and it was reverted. It's still a good starting
point for anyone that would like to run with it,

Cheers,

Nick

[fon...@gmail.com]

I see this in my generated Makefile:

LINKFLAGS = -L/usr/local/lib -Wl,-E
...
LDFLAGS = -L/usr/local/lib

So gcc is pulling libraries from that dir, and if i got an old
libparrot there, it will probably broke the make process.... is this
helpfull??