HP/UX 10.20 and 11.0 broken in 5.1

HP/UX 10.20 and 11.0 broken in 5.1

[Andrew Cagney]

I intend cutting my losses on this.  (And I bet this isn't going to down 
well in some quarters).

11.0 trips up on a problem in ltconfig during configure.

10.20 doesn't build with HP's `cc -Ae' compiler.  It builds with GCC but 
doesn't work.

Andrew

Re: HP/UX 10.20 and 11.0 broken in 5.1

[gdb]

On Mon, Oct 15, 2001 at 10:39:53PM -0400, Andrew Cagney wrote:
> I intend cutting my losses on this.  (And I bet this isn't going to down 
> well in some quarters).
> 
> 11.0 trips up on a problem in ltconfig during configure.
> 
> 10.20 doesn't build with HP's `cc -Ae' compiler.  It builds with GCC but 
> doesn't work.

I'll try to find some time this weekend to help out on this.

-- 
albert chin (china@thewrittenword.com)

Re: HP/UX 10.20 and 11.0 broken in 5.1

[Andrew Cagney]

[ulgh, reply-to was set]
> On Mon, Oct 15, 2001 at 10:39:53PM -0400, Andrew Cagney wrote:
> 
>> I intend cutting my losses on this.  (And I bet this isn't going to down 
>> well in some quarters).
>> 
>> 11.0 trips up on a problem in ltconfig during configure.
>> 
>> 10.20 doesn't build with HP's `cc -Ae' compiler.  It builds with GCC but 
>> doesn't work.
> 
> 
> I'll try to find some time this weekend to help out on this.
> 
> -- albert chin (china@thewrittenword.com)

Thanks.  The thing that is really needed is people with 
assignments/disclaimers in place so that changes can flow freely.

In terms of fixing it, I think sorting this out in the trunk is more 
important.  There are sufficient problems in the trunk that nasty 
retro-fitting will likely be needed to get them working on the trunk.

I have managed to re-produce Brown's GCC warning problems.

Andrew

Re: HP/UX 10.20 and 11.0 broken in 5.1

[Andrew Cagney]

> I intend cutting my losses on this.  (And I bet this isn't going to down well in some quarters).
> 
> 11.0 trips up on a problem in ltconfig during configure.
> 
> 10.20 doesn't build with HP's `cc -Ae' compiler.  It builds with GCC but doesn't work.

Just by way of supporting evidence :-)

The attached patch was a quick attempt at addressing the GCC warnings. 
The thing to notice is that fixing the warnings involves cleaning up 
core-gdb include files.

enjoy,
Andrew
From kimball@sgrail.com Tue Oct 16 13:11:00 2001
From: Kimball Thurston <kimball@sgrail.com>
To: gdb@sources.redhat.com
Subject: gdb and dlopen
Date: Tue, 16 Oct 2001 13:11:00 -0000
Message-id: <y3radyrjqf8.wl@paladin.sgrail.com>
X-SW-Source: 2001-10/msg00157.html
Content-length: 610

Hey all,

   In our application, we've got a plugin architecture that, under
unix, we open using dlopen et al. When trying to debug using gdb, the
process of calling dlopen seems to take an extraordinary amount of
time, as it looks like gdb is using ptrace to copy a bunch of the
debug process's memory at each dlopen into itself. Is there a way to
delay this behavior, or disable it all together, or fix it? I couldn't
determine exactly how gdb uses the memory it copies in. All I know is
it makes using gdb nearly impossible when you have to wait 10 minutes
for the program to start up...

thanks,

Kimball