bug-gnu-utils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: binutils/dllwrap problem


From: Matt Rice
Subject: Re: binutils/dllwrap problem
Date: Thu, 5 Jun 2003 12:55:28 -0700 (PDT)

Hi Nick, thanks for the reply

--- Nick Clifton <address@hidden> wrote:
> Hi Matt,
> > 
> > on this machine running windows millenium edition
> >
> > $ dllwrap --driver-name gcc -o asdf 
> 
> Which version of dllwrap are you using ?

2.13

> > c:\mingw\bin\dllwrap.exe: installation problem,
> cannot
> > exec `gcc': No such file or directory
> 
> Does adding the "--verbose" flag provide any more
> information ?

well, it does provide more information, although none
of it was  useful for this issue, it rather confused
me because it reported DLLTOOL as being
c:/mingw/dlltool because of the argv[0] thing yet was
unable to find gcc still...


> The most likely explanation is that the pexecute()
> system call
> provided by mingw is unable to locate the gcc
> executable, probably
> because it is not finding the correct PATH
> environment variable.  It
> may be that it does not use the Windows path at all.
> 

you seem to be correct on both counts, though why it's
not finding the correct PATH environment variable is
still a good question, my path being set from the
(unmodified) /etc/profile looks something like 

export PATH=.:/usr/local/bin:/bin:/mingw/bin:$PATH

bash seems to be able to cope with this and finds gcc
in /mingw/bin 

through dllwrap doesn't work unless i do a
export PATH=$PATH:\\mingw\\bin

I have a feeling (though haven't tested) that the same
would happen if i specified dlltool to it without the
path addition.

> > passing no driver-name and passing the full path
> to
> > driver-name works, but seems unsatisfactory for
> things
> > like make where the suggested rule is like dllwrap
> > --driver-name $(CC) 
> 
> Given that dllwrap works (for you) without a
> --driver-name switch, why
> not just leave it at that ?
> 

well, they aren't my makefiles, and I don't like being
confused.

<snip>
thanks for the explanation


> The easiest solution would be to modify your make
> rule to something
> like:
> 
>      ... --driver-name `which $(CC)`
> 
> This should then pass the full path for gcc to
> dllwrap and everything
> should work.

well, yeah true, this was my initial thought too but
when running mingw the released version I was getting
which: command not found, running mingw the snapshot
it had a which, though i hadn't realized this yet,
since I just updated to make sure it hadn't been fixed
already
> 
> Cheers
>         Nick

Cheers


__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com




reply via email to

[Prev in Thread] Current Thread [Next in Thread]