libtool-patches
[Top][All Lists]
Advanced

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

Re: [PATCH] lower cap on max_cmd_len to fix hppa2.0w-hp-hpux11.00


From: Robert Boehne
Subject: Re: [PATCH] lower cap on max_cmd_len to fix hppa2.0w-hp-hpux11.00
Date: Mon, 09 Jul 2001 13:19:27 -0500

Michael:

The bug report at 
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&database=gcc&pr=3055
shows that the problem is intermittent, the reporter verifies that
--with-system-zlib allows him to build gcc 3.0.  I am assuming that
ltconfig is being run for at least one other library without error.

> Libtool does not work with vendor software.  If your response is "install
> patches to the vendor software" then you need some documentation to
> describe what version of vendor software *does* work.

I don't buy into this argument.  Libtool does work with vendor software.
If the case was that every hp 11.0 machine (or nearly every one)
couldn't
use libtool, then I would advocate the change to work around the
problem.
  It is also not up to Libtool to support HPUX, creating a string of
1MB in length is not an unreasonable requirement of the shell, and usage
of 57MB may be more than we'd like, it is very reasonable to expect a
machine to be capable of this.  I am running:
HP-UX luna B.11.00 A 9000/782 2005520202 two-user license
which seems very similar to your machine, however this does not tell us
if any patches have been applied, or what they may have been.  I would
advise you to check with HP, I woudn't be happy if my expensive OS could
not execute relatively simple shell code.  I really am sorry you are
having trouble, but Libtool does not seem to be the problem.
  The reason you don't have any change in performance when you lower
this
limit is that your project (gcc) doesn't build large libraries.  In
projects
that do, piecewise linking needs to use the largest command line
possible
to link quickly.  Cutting that number in half will result in about twice
as many links to get the same library, a huge performance hit.  I would
actually consider this change if, and only if, there is not a bug in
the OS that is the problem (can you prove a negative)?  ;)
  Talk with the HP support people, and let me know what they say.  Deal?

Cheers!

Robert

Michael Elizabeth Chastain wrote:
> 
> I'm looking at this from the standpoint of trying to build gcc 3.0 on
> this machine.  gcc 3.0 uses ltconfig, and ltconfig comes from libtool.
> 
> If I work around the problem by patching ltconfig, then my gcc 3.0 build
> works just fine.
> 
> Other people have the same problem:
> 
>   http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&database=gcc&pr=3055
> 
> My machine id is:
> 
>   HP-UX behemoth B.11.00 U 9000/800 2003254751 unlimited-user license
> 
> What is yours?  Are you running B.11.00, or a later OS?
> 
> The machine has more than 392 MB of physical memory (that's the largest
> single process I've ever run, and it's all resident).  It's a development
> machine and I'm the only user on it when I'm building stuff.
> 
> I'm running "top" in one window and libtool "configure" in another.
> I see a /bin/sh process that expands to about 57 MB, and then
> it dies.
> 
> > Are there shell bugs that you don't have patches for?
> 
> This is more likely.  I know that it's not a process size limit,
> because I can run a single process of 392 MB just fine.
> 
> > IMHO, this isn't a libtool problem.
> 
 
> Meanwhile I need to prepare a source tree that builds on a wide variety
> of hpux 11.00 machines, including those that do not have unspecified
> patches to the vendor software.  Do you have any suggestions about how
> to do this in a way that will be accepted into the libtool sources?
> Because I'm at the point now of just producing my own local change.
> 
> Michael Elizabeth Chastain
> <address@hidden>
> "love without fear"

-- 
Robert Boehne             Software Engineer
Ricardo Software   Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email:  address@hidden



reply via email to

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