Re: Fix gdb 7.12 C++ compilation on Solaris

[Pedro Alves <palves at redhat dot com>]

On 10/14/2016 03:45 PM, Rainer Orth wrote:
> gdb 7.12 doesn't compile as C++ (tried with g++ 4.9) on Solaris (tried
> 10 and 12, sparc and x86).  The following patch (relative to the 7.12
> release, though I expect most if not all issues to be present on trunk,
> too) fixes this.
> 
> Only a few of the changes bear explanation:
> 
> * Initially, compilation failed whereever defs.h. was included:
> 
> In file included from /vol/src/gnu/gdb/gdb-7.12/gdb/gdb.c:19:0:
> /vol/src/gnu/gdb/gdb-7.12/gdb/defs.h:630:33: error: 'double atof(const char*)' conflicts with a previous declaration
>  extern double atof (const char *); /* X3.159-1989  4.10.1.1 */
>                                  ^
> In file included from /usr/include/stdlib.h:17:0,
>                  from build-gnulib/import/stdlib.h:36,
>                  from /vol/src/gnu/gdb/gdb-7.12/gdb/common/common-defs.h:32,
>                  from /vol/src/gnu/gdb/gdb-7.12/gdb/defs.h:28,
>                  from /vol/src/gnu/gdb/gdb-7.12/gdb/gdb.c:19:
> /vol/gcc-4.9/lib/gcc/i386-pc-solaris2.10/4.9.0/include-fixed/iso/stdlib_iso.h:119:15: note: previous declaration 'double std::atof(const char*)'
>  extern double atof(const char *);
>                ^
> 
>   This is due to this gem in gdb/defs.h which seems to have been present
>   like forever:
> 
> #ifndef atof
> extern double atof (const char *);	/* X3.159-1989  4.10.1.1 */
> #endif
> 
>   In the Solaris headers, the appropriate functions are in namespace std,
>   thus the conflict.  I've wrapped the defs.h declaration in !__cplusplus
>   to avoid this; perhaps it can go completely instead.

master dropped support for building with a C compiler, it's C++-only.
So for master, just delete the thing.

On both branches, please delete the whole comment above as well:

 /* Global functions from other, non-gdb GNU thingies.
    Libiberty thingies are no longer declared here.  We include libiberty.h
    above, instead.  */

 /* From other system libraries */

as it no longer makes any sense afterwards.

> 
> * All the casts are necessary to appease g++ and should be pretty
>   obvious.
> 
> * The sol-thread.c changes are here to handle
> 
> /vol/src/gnu/gdb/gdb-7.12/gdb/sol-thread.c: In function 'void _initialize_sol_thread()':
> /vol/src/gnu/gdb/gdb-7.12/gdb/sol-thread.c:1252:36: error: invalid conversion from 'void*' to 'void (*)(int)' [-fpermissive]
>    if (!(p_##X = dlsym (dlhandle, #X))) \
>                                     ^
> /vol/src/gnu/gdb/gdb-7.12/gdb/sol-thread.c:1255:3: note: in expansion of macro 'resolve'
>    resolve (td_log);
>    ^
> 
>   and are modeled after linux-thread-db.c (try_thread_db_load_1).
> 
> The patch allowed both 32 and 64-bit C++ builds on sparc-sun-solaris2.10
> and i386-pc-solaris2.10 to complete.  The resulting binary hasn't seen
> more than a smoke test (invoke it on itself, b main, run) yet.
> 
> Ok for mainline and 7.12 branch?

Yes, with the tweak above on master.  But, the process for getting
fixes into the branch involves filing a PR.  The reason is that the
PR's subject is later used to help create the release announcement
(manually).  So please file a bug ("gdb 7.12 doesn't build on Solaris"
or some such, and paste an example build error log).

> Besides, when I compiled with g++ 4.9 installed into a non-default
> location, gdb wouldn't run initially since libstdc++.so.6 and
> libgcc_s.so.1 weren't found.  Maybe it would be good to handle this as
> gcc does and just link with -static-libstdc++ -static-libgcc?

That's already included in the link line for me on GNU/Linux.
Maybe it's host-specific?  I've wondered before about why don't
we use rpath instead though.

Thanks,
Pedro Alves