The configure check for ld fails
Here's the output of running sh -x configure:
+ echo -n checking for ld used by GCC...
checking for ld used by GCC... + echo configure:1443: checking for ld used
by GCC
+ ac_prog=GCC -print-prog-name=ld
/usr/libexec/elf/ld
+ with_gnu_ld=unknown
+ echo ${lt_c
Sorry. My error. I had a debugging script named gcc in my path, and
configure didn't like it.
FWIW, all it was, was:
#!/bin/sh
echo GCC "$@"
exec /usr/bin/gcc "$@"
Of course, since configure was trying to do --print-program-name and use the
output of standard out, it barfed. Understandable.
Mo
Title: ::: ÆĶóÁÖ¶ó ¸ÞÀÏ ¹ß¼Û :::
¸ÕÀú »çÀü ¾çÇؾøÀÌ ¸ÞÀÏÀ» º¸³»µå·Á Á˼ÛÇÕ´Ï´Ù.
º» ¸ÞÀÏÀº Á¤ÅëºÎ ±Ç°í»çÇ׿¡ ÀÇ°Å Á¦¸ñ¿¡(±¤°í)¶ó
Alan Eldridge <[EMAIL PROTECTED]> writes:
> The configure check for ld fails
Apparently libtool insists on finding the `ld' executable. Is it
available on your machine?
Hello Hrvoje,
>
> > I think the 'timestamping' is the point, because without that I see
> > that no .listing file is used at all, and the problem doesn't
> > appear.
>
> Yes, with the timestamping turned on, I was able to repeat the
> problem. This patch should fix it:
>
> 2001-12-02 Hrvoje
On Wed, Dec 05, 2001 at 07:25:12PM +0100, Hrvoje Niksic wrote:
>Alan Eldridge <[EMAIL PROTECTED]> writes:
>
>> The configure check for ld fails
>
>Apparently libtool insists on finding the `ld' executable. Is it
>available on your machine?
See my followup post. My fault. Debugging script for
Daniel Stenberg <[EMAIL PROTECTED]> writes:
> On Mon, 24 Sep 2001, Lenny Foner wrote:
>
>> utils.c:906: failed assertion `length > 0'
>
> This is the key issue here.
>
> The "file" read by wget (which happens to be a directory in this
> case) returns a zero length line and the assert() line wa
I have recently tripped across a bug with the
version of wget shipped with RedHat 7.2. When I attempt to recursively
retrieve a web tree starting with an html link that contains a base href, wget
apparently limits all href to base href even if another absolute path is
specified. You can ve
"William H. Gilmore" <[EMAIL PROTECTED]> writes:
> I have recently tripped across a bug with the version of wget shipped
> with RedHat 7.2. When I attempt to recursively retrieve a web tree
> starting with an html link that contains a base href, wget apparently
> limits all href to base href eve
This patch fixes the long-standing bug in logvprintf that made Wget
dump core on PowerPC (and probably other, less-known architectures).
The problem was that logvprintf called vsnprintf, which would "spend"
the va_list given to it. A correct caller is expected to call
va_start and va_end before
I am not aware of any remaining outstanding issues for 1.8, so "pre1"
sounds better than "beta4". Hopefully, this one should compile
cleanly on MacOS X and Windows, in addition to Unix-like OS-es.
Get it from:
ftp://gnjilux.srk.fer.hr/pub/unix/util/wget/.betas/wget-1.8-pre1.tar.gz
(The `.b
11 matches
Mail list logo
