This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Issue with Latest GDB on AIX with GCC-6.12
Hi All !
I have created a bug for this issue. The bug id is: 21187.
I have created a patch for configure file in which new configure
option --enable-staticlib and --disable-staticlib is implemented.
By default the linking of GDB with libstdc++ and libgcc will be static.
Attching the patch with the mail.
On Mon, Feb 13, 2017 at 9:08 PM, Nitish Kumar Mishra
<mishra.nitish.88@gmail.com> wrote:
> 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