From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andrew Cagney <ac131313@cygnus.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: gdb@sources.redhat.com
Subject: Re: HP/UX 10.20 and 11.0 broken in 5.1
Date: Tue, 16 Oct 2001 10:40:00 -0000
Message-id: <3BCC70FE.4010205@cygnus.com>
References: <3BCB9DF9.2070809@cygnus.com>
X-SW-Source: 2001-10/msg00156.html

> 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