Re: Experiences building and using gdb 6.8 on Solaris

[Hui Zhu <teawater at gmail dot com>]

Hi Frank,

Could you try your issue with gdb-cvs-head version?
You can get it in ftp://sourceware.org/pub/gdb/snapshots/current/ .

Thanks,
Hui

On Mon, Apr 27, 2009 at 04:52, Frank Middleton <f.middleton@apogeect.com> wrote:
> Not sure if this is the correct list, but maybe someone here is interested
> in some Solaris issues
>
> This is on snv103 (SunOS 5.11) for SPARC, with make aliased to gmake.
>
> Biggest problem is that make distclean doesn't remove any of the cache
> files, so the make fails miserably if, for example, you change LDFLAGS.
>
> In order to get it to build, it was necessary to get the latest ncurses,
> and to build that --with-shared, and, as usual, remember not to use
> Solaris /bin/sh.
>
> The motivation to build the latest gdb is the following error with
> GNU gdb 6.3.50_2004-11-23-cvs
> ...
> elfread.c:366: internal-error: sect_index_data not initialized
> ...
>
> but, alas, it still fails with GNU gdb 6.8
> ...
> elfread.c:424: internal-error: sect_index_data not initialized
> A problem internal to GDB has been detected,
> further debugging may prove unreliable.
>
> Aside from the optimism of the last line (further debugging appears
> to be impossible), is this a known problem? It is proving to be rather
> difficult to make a simple test case, and extensive Googling found
> little other than that something similar had been fixed a while ago.
>
> Gdb runs simple executables just fine. The problem comes when linking
> and running an executable containing a mix of libraries compiled using
> Sun cc (i.e. the system libraries), some 3rd party libraries, probably
> compiled using a relatively old gcc (3.4.2), and a relatively new
> gcc (4.3.2) locally. Truss shows that the last library to be opened
> was /usr/lib/libXau.so.6. Both versions of gdb emit this warning:
> warning: Lowest section in /usr/lib/libdl.so.1 is .SUNW_syminfo at 00000094
> AFAIK Sun ld was used for linking throughout. The application actually
> run properly if you run it without gdb.
>
> Any insights much appreciated...
>
>
>