Re: Issue with Latest GDB on AIX with GCC-6.12

Nitish,

Patches should be sent to the gdb-patches mailing list with a new
email thread. Please follow the format for email subject lines.

configure is a generated file, so you must patch configure.ac and then
be able to use the correct version of autoconf to regenerate the file.

There already is a variable have_static_libs, so it may be more useful
to re-use that variable than to create another one with much the same
functionality.

Thanks, David

On Tue, Feb 21, 2017 at 12:00 AM, Nitish Kumar Mishra
<[email protected]> wrote:
> Hi All !
>
> The previous patch file has issues while patching. I mistakenly sent it.
> I am attaching the updated one.
>
> Thanks and Regards
> Nitish.
>
> On Mon, Feb 20, 2017 at 5:07 PM, Nitish Kumar Mishra
> <[email protected]> wrote:
>> Hi All !
>> The proposed patch is tested on AIX-7.2 and Ubuntu-16.04 and it seems
>> to be working fine.
>>
>> Thanks,
>> Nitish.
>>
>> On Mon, Feb 20, 2017 at 4:55 PM, Nitish Kumar Mishra
>> <[email protected]> wrote:
>>> Hi All !
>>>
>>> Please find the patch attachment with this mail.
>>> Any comments are more than welcome.
>>>
>>> Thanks,
>>> Nitish
>>>
>>> On Mon, Feb 20, 2017 at 4:52 PM, Nitish Kumar Mishra
>>> <[email protected]> wrote:
>>>> 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
>>>> <[email protected]> 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 <[email protected]> wrote:
>>>>>>> From: David Edelsohn <[email protected]>
>>>>>>> Date: Mon, 13 Feb 2017 10:02:35 -0500
>>>>>>> Cc: Nitish Kumar Mishra <[email protected]>, "[email protected]" <[email protected]>,      Yao Qi <[email protected]>
>>>>>>>
>>>>>>> >> 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