bug-libtool
[Top][All Lists]
Advanced

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

Re: ltmain.sh problem


From: David Relson
Subject: Re: ltmain.sh problem
Date: Thu, 27 Nov 2003 11:24:50 -0500

On Thu, 27 Nov 2003 16:05:06 +0000
"Gary V. Vaughan" <address@hidden> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> In public please :-)

Hi Gary,

Public is great.  I didn't have the list address :-(

As the bad ltmain.sh is distributed with sylpheed-claws, I'm CC'ing this
message to that list, in hopes of hearing from the person who included
the problematic ltmain.sh with the tarball.

I'd try building 1.5.0a myself except that 1.4.3 is the newest version
available from the gnu mirrors and my attempts to check it out from cvs
also give me 1.4.3.  Have you any suggestions?

Thanks.

David

> David Relson wrote:
> | At a user of sylpheed-claws I periodically find myself building it
> | afresh, with ./configure && make && etc, etc, etc.  In the process
> of| doing that, I've encountered two problems with ltmain.sh.
> |
> | First, variable SED is used without being defined.  I've fixed the
> | problem with the patch below.
> |
> | Second, multiple "integer expression expected" complaints are
> printed.| In ltmain.sh there are multiple references to $max_cmd_len,
> which is| never defined.  I have not idea what to do with this second
> problem,| though the build appears to succeed in spite of it.
> |
> | SC ships with the ltmain.sh from v1.5.0a of libtools.  For your
> | reference, I've attached a copy of the file.
> 
> It appears that your libtool script is not being generated properly:
> 
> ~  $ egrep -e '^SED=' -e '^max_cmd_len=' +build/libtool
> ~  SED="/bin/sed"
> ~  max_cmd_len=32768
> ~  max_cmd_len=32768
> ~  max_cmd_len=32768
> ~  max_cmd_len=32768
> ~  max_cmd_len=32768
> 
> LT_AC_PROG_SED is responsible for finding a working sed program and
> storing it in SED, and AC_LIBTOOL_SYS_MAX_CMD_LEN is responsible for
> finding the longest command line the shell will accept without
> truncation and saving the value in max_cmd_len.
> 
> Is everything being stored in config.status correctly?  Try looking at
> config.log and see if any of the tests I mentioned above fail...
> 
> Cheers,
>       Gary.




reply via email to

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