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
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
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
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
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 the
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
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 changed by the
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
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
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
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
12 matches
Mail list logo
