On 8/2/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
On 8/2/06, Leopold Toetsch <[EMAIL PROTECTED]> wrote: > Am Mittwoch, 2. August 2006 19:52 schrieb [EMAIL PROTECTED]: > > > 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). 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...
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??
> leo > -- Will work for bandwidth
-- Will work for bandwidth
