Re: [PATCH 0/2] gdb: Require a C++11 compiler

[Pedro Alves <palves at redhat dot com>]

On 11/04/2016 01:31 PM, Maciej W. Rozycki wrote:
> On Tue, 1 Nov 2016, Pedro Alves wrote:
> 
>>> to mess with either forcing static linking or worse, forcing uses to
>>> mess with non-standard LD_LIBRARY paths at run time.
>>
>> Note that just like gcc, gdb builds with -static-libstdc++ -static-libgcc.
> 
>  Are you sure?  All my recent cross-built `gdbserver' executables failed 
> to run without a pain of getting `libstdc++.so' in the right place on the 
> target.  Or do you mean GDB proper only?  I didn't even realise there was
> intention to use static `libstdc++' and/or `libgcc' libraries.

Hmm.  I do see it on my builds.  

 $ rm gdbserver && make gdbserver 2>&1 | grep static
 ... -Wformat-nonliteral -Werror -DGDBSERVER -static-libstdc++ -static-libgcc  ...

I guess the the difference is that I'm looking at a native build, which means
that gdb/gdbserver/configure is run as a subdir of the gdb configure which in
turn is a subdir of the top level configure.  It's the top level configure
that adds the -static-*:

 ...
 # Check whether -static-libstdc++ -static-libgcc is supported.
 ...

But if you cross-build gdbserver, you'll be running gdbserver's
configure directly, bypassing the top level, and thus miss that.

Maybe we should move that bit of configure code to an .m4 file
under src/config/, and then the different subdirs could include
use of it as they saw fit.  Maybe even make it optional under
a configure --whatever option.  Maybe distros would prefer
disabling that.

(Or make gdbserver be the toplevel subdir, but even though
desirable, that's obviously a much larger change...)

>  Also I've not been particularly happy with the project moving over to C++ 
> let alone C++11, however I have just decided I couldn't afford the effort 
> to go through all the discussion, which always takes time pinched from 
> other commitments.  Being a CPU target maintainer only and with my rusty 
> 1995-vintage C++ programming skills -- making it difficult to me to assess 
> what the advantages of modern C++ dialects might be -- I didn't want to 
> stand in the way of core developers if they think a move to C++ will make 
> their job easier, improving code quality and reducing maintenance burden.
> 

Thanks for understanding.

Thanks,
Pedro Alves