Fix gdb 7.12 C++ compilation on Solaris

  Hi Pedro,

> 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.

done in the attached revised patch.

>> * 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

Thanks.  When investigating the failure to detect -static-libstdc++
support (more below), I found two more issues which only show up with
-Werror:

/vol/src/gnu/gdb/gdb/local/gdb/procfs.c: In function 'ssd* proc_get_LDT_entry(procinfo*, int)':
/vol/src/gnu/gdb/gdb/local/gdb/procfs.c:2487:19: error: variable 'old_chain' set but not used [-Werror=unused-but-set-variable]
   struct cleanup *old_chain = NULL;
                   ^

Unless I'm mistaken, you need to run do_cleanups on every return from
the function.

Afterwards, I ran a 32-bit compilation, which (after adding
--disable-largefile to avoid

In file included from /usr/include/sys/procfs.h:28:0,
                 from /vol/src/gnu/gdb/gdb/local/gdb/i386-sol2-nat.c:23:
/usr/include/sys/old_procfs.h:39:2: error: #error "Cannot use procfs in the large file compilation environment"
 #error "Cannot use procfs in the large file compilation environment"
  ^

and two more instances) revealed

/vol/src/gnu/gdb/gdb/local/gdb/top.c: In function 'void gdb_safe_append_history()':
/vol/src/gnu/gdb/gdb/local/gdb/top.c:1170:59: error: format '%d' expects argument of type 'int', but argument 3 has type 'pid_t {aka long int}' [-Werror=format=]
     = xstrprintf ("%s-gdb%d~", history_filename, getpid ());
                                                           ^

Fixed by casting pid_t to long and printing it as such.

Still ok for mainline?

> 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).

Done now (PR build/20712).

>> 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.

This turned out to be (sort of) pilot error: since I'd started with
building a 64-bit gdb with a 32-bit-default gcc, I had to configure with
CFLAGS='-g -O2 -m64' and now added CXXFLAGS='$(CFLAGS)'.  However, this
didn't work as intended, but passed a literal "$(CFLAGS)" to C++
compilations, breaking/confusing several configure tests like the one
for -static-libstdc++ or the -Werror one.  Once I duplicated the
necessary options in CXXFLAGS, everything went fine and libstdc++ was
linked statically as expected.

	Rainer

Fix gdb 7.12 C++ compilation on Solaris

Commit Message

Comments

Patch