Issue with Latest GDB on AIX with GCC-6.12

[Nitish Kumar Mishra]

Hi David !

>Who built GCC 6.1 for you?  Is this an IBM build or Bull Freeware?
IBM does not have GCC-6 build yet, and generally Bull's rpm breaks our
environment. I took it from perzl.org.
But now I have tested it with Bull's RPM, static linking still not
working but removing --static-libstdc++ and --static-libgcc
is working for me as well.
Now, I will run the testsuite and will paste the result once it's finished.

I disabled the static options manually. I don't see any configure
option for disabling the static linking. I tried with one configure
option --disable-libstdcxx, but I dont think it will lead to dynamic
linking. Anyways, for me, using this option --disable-libstdcxx
was giving compilation error, saying, "ld soes not support target".

Thanks,
Nitish


On Mon, Feb 13, 2017 at 8:49 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: David Edelsohn <dje.gcc@gmail.com>
>> Date: Mon, 13 Feb 2017 10:02:35 -0500
>> Cc: Nitish Kumar Mishra <mishra.nitish.88@gmail.com>, "gdb@sourceware.org" <gdb@sourceware.org>,      Yao Qi <qiyaoltc@gmail.com>
>>
>> >> Can we disable -static-libgcc and -static-libstdc++ for AIX?
>> >
>> > Works for me.  Those are added by the top level configure.  They were
>> > originally added for gcc, we just inherited it.  Ideally adding
>> > those would be controllable with a configure option, IMO.
>>
>> We shouldn't disable static-libgcc and static-libstdc++ for GCC.  And
>> static would be better.  But linking GDB dynamically could be helpful
>> as an interim work-around.
>
> Please let's not do that on MS-Windows at least.  Dynamically linking
> against these two libraries has the following 2 adverse effects:
>
>   . it requires any site that distributes precompiled Windows binaries
>     of GDB to also distribute the full humongous tarball of GCC
>     sources (because libgcc runtime exception doesn't cover dynamic
>     linking against shared libraries); and
>
>   . it opens the gates of the "DLL hell", since there's any number of
>     libgcc and libstdc++ DLLs from different versions of GCC floating
>     around on any given Windows system with GNU software, and there's
>     no practical way to ensure binary compatibility between the one
>     found first on PATH and a particular version of GDB one wants to
>     run