Charles Wilson wrote:
Okay, the patch I posted to libtool-patches works on my system (of
course, the UNpatched libtool works on my system) -- but the patch ought
to fix this problem. It hunts specifically for head.exe and uses that,
if found, falling back to 'head' only if 'head.exe' is not fou
Okay, the patch I posted to libtool-patches works on my system (of
course, the UNpatched libtool works on my system) -- but the patch ought
to fix this problem. It hunts specifically for head.exe and uses that,
if found, falling back to 'head' only if 'head.exe' is not found in the
path.
I'd
Igor Pechtchanski wrote:
FYI, in my case it made the error more apparent (something like
"/usr/bin/tail: no such file or directory"), but no less cryptic.
The temporary fix is to rename /bin/HEAD to /bin/HEAD.pl (along with the
other two scripts, just for consistency). If it ever gets accepted in
David Starks-Browning wrote:
On Friday 7 Mar 03, Teun Burgers writes:
I've found the culprit. I installed the perl LWP module which
installs a HEAD script that fetches the header of an URL.
On unix HEAD and head are different but on cygwin having
both HEAD and head.exe along the path causes a pr
On Fri, 7 Mar 2003, David Starks-Browning wrote:
> On Friday 7 Mar 03, Teun Burgers writes:
> > I've found the culprit. I installed the perl LWP module which
> > installs a HEAD script that fetches the header of an URL.
> > On unix HEAD and head are different but on cygwin having
> > both HEAD and
On Friday 7 Mar 03, Teun Burgers writes:
> I've found the culprit. I installed the perl LWP module which
> installs a HEAD script that fetches the header of an URL.
> On unix HEAD and head are different but on cygwin having
> both HEAD and head.exe along the path causes a problem...
Would CYGWIN=c
On Fri, 7 Mar 2003, Teun Burgers wrote:
> Teun Burgers wrote:
> >
> > Charles Wilson wrote:
> >
> > > Now, about your problem: I'm a bit confused, because I do *not* see that
> > > behavior. Please take the attached script, which contains only the new
> > > win32_libid() code -- the only parted c
Teun Burgers wrote:
Charles Wilson wrote:
Now, about your problem: I'm a bit confused, because I do *not* see that
behavior. Please take the attached script, which contains only the new
win32_libid() code -- the only parted changed by the patched
libtool-20030216 -- and run the following tests
Teun Burgers wrote:
>
> Charles Wilson wrote:
>
> > Now, about your problem: I'm a bit confused, because I do *not* see that
> > behavior. Please take the attached script, which contains only the new
> > win32_libid() code -- the only parted changed by the patched
> > libtool-20030216 -- and run
Charles Wilson wrote:
> Now, about your problem: I'm a bit confused, because I do *not* see that
> behavior. Please take the attached script, which contains only the new
> win32_libid() code -- the only parted changed by the patched
> libtool-20030216 -- and run the following tests:
>
> ./cygwin
Teun Burgers wrote:
When I libtoolize with libtool-devel-20030216, I can't build dll's that I was able to
build with libtool-devel-20030103. When linking with 20030216 I get messages such
as these:
[snip]
I get this message for the following libs:
-lcygwin -luser32 -ladvapi32 -lkernel32 -lshell3
When I libtoolize with libtool-devel-20030216, I can't build dll's that I was able to
build with libtool-devel-20030103. When linking with 20030216 I get messages such
as these:
*** Warning: linker path does not have real file for library -lcygwin.
*** I have the capability to make that library au
12 matches
Mail list logo
