On 4/30/24 8:43 AM, Gaius Mulley wrote:
> Christophe Lyon writes:
>
>> On Tue, 30 Apr 2024 at 04:01, Simon Marchi wrote:
>>>
>>> I get a diff when running "autoreconf" in this directory. I think that
>>> the current state is e
On 4/30/24 4:54 AM, Christophe Lyon wrote:
> On Tue, 30 Apr 2024 at 04:25, Simon Marchi wrote:
>>
>> Add an "AC_CONFIG_MACRO_DIRS" call in configure.ac, with the same
>> directories as specified in "ACLOCAL_AMFLAGS", in Makefile.in.
>>
>> T
Add an "AC_CONFIG_MACRO_DIRS" call in configure.ac, with the same
directories as specified in "ACLOCAL_AMFLAGS", in Makefile.in.
This makes it possible to re-generate aclocal.m4 using "autoreconf".
---
fixincludes/configure| 1 +
fixincludes/configure.ac | 1 +
2 files changed, 2
I get a diff when running "autoreconf" in this directory. I think that
the current state is erroneous: it appears to have been generated using
aclocal -I ../config -I ..
even though configure.ac and Makefile.am list the include flag in the
reverse order:
aclocal -I .. -I ../config
Hi gcc-patches,
I had applied the patch below to binutils-gdb, but it recently got wiped
out by a gcc -> binutils-gdb configure.ac sync. Would it be possible to
apply it to the gcc repo so this doesn't happen again?
Thanks,
Simon
On 2022-03-15 17:26, Simon Marchi via Gdb-patches wrote:
>
Add
AC_CONFIG_MACRO_DIRS([../config])
So that just running:
$ autoreconf -vf
... does the right thing (no need to specify -I ../config).
Note: I don't have access to the gcc repo, so if this patch is approved,
can somebody push it there on my behalf? I can push it to binutils-gdb.
On 2022-04-08 10:32, Nick Clifton wrote:
> Hi Simon,
>
>> Ping.
>
> Patch approved - please apply.
>
> I appreciate that modifying these top level files is a bit nerve
> wracking, but I think that you have done a good job in this case. :-)
>
> Cheers
> Nick
>
Thanks Nick, pushed.
Simon
Ping.
On 2022-03-29 16:04, Simon Marchi wrote:
> Ping!
>
> On 2022-03-15 17:26, Simon Marchi wrote:
>> From: Simon Marchi
>>
>> [Sending to binutils, gdb-patches and gcc-patches, since it touches the
>> top-level Makefile/configure]
>>
>> I have my d
Ping!
On 2022-03-15 17:26, Simon Marchi wrote:
> From: Simon Marchi
>
> [Sending to binutils, gdb-patches and gcc-patches, since it touches the
> top-level Makefile/configure]
>
> I have my debuginfod library installed in a non-standard location
> (/opt/debuginfod), whi
From: Simon Marchi
[Sending to binutils, gdb-patches and gcc-patches, since it touches the
top-level Makefile/configure]
I have my debuginfod library installed in a non-standard location
(/opt/debuginfod), which requires me to set
PKG_CONFIG_PATH=/opt/debuginfod/lib/pkg-config. If I just set
On 2021-05-04 8:42 a.m., Nick Clifton wrote:
> Hi Guys,
>
> On 4/30/21 7:36 PM, Simon Marchi wrote:
>> I think this fix is obvious enough, I encourage you to push it,
>
> OK - I have pushed the patch to the mainline branches of both
> the gcc and binutils-gfdb r
On 2021-05-03 5:51 p.m., Alan Modra wrote:
> I wasn't talking about running configure, I was talking about running
> make. For example, you configure and make binutils as usual, then
> after making a change to ld/ files, run make in the ld build dir. I
> don't tend to do that myself but I do run
> Yes, I prefer the configure fix too. If we state we require C99 in
> binutils then we ought to be able to use C99..
>
> Nick, does the configure.ac change also need to go in all subdirs, to
> support people running make in say ld/ rather than running make in the
> top build dir?
For GDB, it's
On 2021-04-26 7:32 a.m., Nick Clifton via Gdb-patches wrote:> Hi Guys,
>
> Given that gcc, gdb and now binutils are all now requiring C99 as a
> minimum version of C, are there any objections to updating
> configure.ac to reflect this ?
>
> Cheers
> Nick
>
> diff --git a/configure.ac
Bring in a few lines that are in binutils-gdb's .gitignore but not
gcc's.
Note that I don't have push access to gcc, so I would appreciate
if somebody could push it for me.
ChangeLog:
* .gitignore: Sync with binutils-gdb.
---
.gitignore | 7 +++
1 file changed, 7 insertions(+)
Hi,
I'm currently squashing some bugs related to .debug_rnglists in GDB, and
I happened to notice that clang and gcc do different things when
generating rnglists with split DWARF. I'd like to know if the two
behaviors are acceptable, and therefore if we need to make GDB accept
both. Or maybe
On 2020-07-28 2:31 p.m., H.J. Lu wrote:
>>> Unlike gdb, binutils should have as few external depecies as possible.
>>> debuginfod brings in some so many external depecies.
>>
>> I'm not a binutils maintainer, so that's not my role to decide about that
>> tradeoff... but we are talking about having
On 2020-07-28 1:26 p.m., H.J. Lu wrote:
> On Tue, Jul 28, 2020 at 9:28 AM Simon Marchi wrote:
>>
>> On 2020-07-28 12:07 p.m., H.J. Lu via Gdb-patches wrote:
>>> What doesn't work with my pkg.m4 change?
>>
>> (1) It deviates from upstream. I don't think we sho
On 2020-07-28 12:07 p.m., H.J. Lu via Gdb-patches wrote:
> What doesn't work with my pkg.m4 change?
(1) It deviates from upstream. I don't think we should do this unless
absolutely needed. That's not the case here, the change is just there
because you don't want to set up pkg-config
On 2020-07-28 11:05 a.m., H.J. Lu via Gdb-patches wrote:
>> Can you clarify how this magic works, is this standard autoconf? Because I
>> am trying this
>> on Fedora, so pretty much the same setup as you, and I don't see this
>> behavior:
>>
>> $ /home/simark/src/binutils-gdb/configure CC="gcc
On 2020-07-28 10:11 a.m., H.J. Lu wrote:
> On Tue, Jul 28, 2020 at 7:01 AM Simon Marchi wrote:
>>
>> On 2020-07-28 9:56 a.m., H.J. Lu wrote:
>>> On Tue, Jul 28, 2020 at 6:51 AM Andreas Schwab
>>> wrote:
>>>>
>>>> On Jul 28 2020, H.J. Lu
On 2020-07-28 9:56 a.m., H.J. Lu wrote:
> On Tue, Jul 28, 2020 at 6:51 AM Andreas Schwab wrote:
>>
>> On Jul 28 2020, H.J. Lu via Binutils wrote:
>>
>>> On x86, the native GCC can support -m32 and -m64. "gcc -m32" or "gcc -m64"
>>> are not cross compiling.
>>
>> You cannot link -m64 and -m32
On 2020-07-28 9:33 a.m., H.J. Lu wrote:
> On x86, the native GCC can support -m32 and -m64. "gcc -m32" or "gcc -m64"
> are not cross compiling.
And how does that make it not cross-compîling?
>> Anyway regardless of vocabulary, I don't think there was a problem to begin
>> with (not that I
On 2020-07-28 6:45 a.m., H.J. Lu wrote:
> On Mon, Jul 27, 2020 at 12:32 PM H.J. Lu wrote:
>>
>> On Mon, Jul 27, 2020 at 12:14 PM H.J. Lu wrote:
>>>
>>> On Mon, Jul 27, 2020 at 9:11 AM Aaron Merey wrote:
On Mon, Jul 27, 2020 at 11:32 AM H.J. Lu wrote:
>
> On Sat, Jul 25, 2020
On 2020-07-16 6:37 p.m., Aaron Merey wrote:
> On Fri, May 8, 2020 at 4:56 PM Tom Tromey wrote:
>>
>>> "Aaron" == Aaron Merey via Binutils writes:
>>
>> Aaron> * Makefile.in: Replace LIBDEBUGINFOD with DEBUGINFOD_LIBS.
>> Aaron> * aclocal.m4: Rebuild.
>>
>> Instead of inlining
On 2019-04-16 12:39 a.m., Eric Gallager wrote:
> Hey Montréal, I might actually be able to go this year! How do I register?
Hi Eric,
Happy to hear this! Please see the Registration section on the wiki:
https://gcc.gnu.org/wiki/cauldron2019#Registration
Simon
On 2019-04-15 12:42 p.m., Simon Marchi wrote:
> Hi,
>
> Here is a patch that adds a mention of the 2019 Cauldron, similar to the
> entries
> for the previous editions.
>
> Thanks,
>
> Simon
>
>
> Index: index.html
> ==
Hi,
Here is a patch that adds a mention of the 2019 Cauldron, similar to the entries
for the previous editions.
Thanks,
Simon
Index: index.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v
retrieving revision 1.1125
diff -u
From: Дилян Палаузов
[I (Simon) just pushed this to binutils-gdb, please consider merging it
in gcc to keep the files sync-ed(-ish).]
https://sourceware.org/bugzilla/show_bug.cgi?id=18632
The bundled libreadline is always built, even if the system is
./configure'd --with-system-readline and
On 2018-12-14 5:39 p.m., Jason Merrill wrote:
> GDB/binutils folks, how do you want to handle this? Shall I go ahead
> with this patch, with the understanding that there will be associated
> changes necessary when merging it into the binutils-gdb repository, or
> go with the small disabling patch
On 2018-11-06 11:37, Hafiz Abid Qadeer wrote:
Hi All,
I was investigating a character set related problem with windows hosted
GDB and I tracked it down to a typo in iconv.m4. This typo caused
libiconv detection to fail and related support was not built into gdb.
The problem is with the
On 2018-10-30 11:26 p.m., Joseph Myers wrote:
> This patch (diffs to generated files omitted below) updates GCC to use
> autoconf 2.69 and automake 1.15.1. (That's not the latest automake
> version, but it's the one used by binutils-gdb, with which consistency
> is desirable, and in any case
On 2018-08-01 03:58 PM, Simon Marchi wrote:
> This patch was tested to build binutils-gdb on GNU/Linux and macOS. It can be
> applied to the gcc repo too, after fixing some trivial merge conflicts
> (someone
> else will need to do it, as I don't have push access to gcc). Althoug
(CCing gcc-patches because of the change in include/dwarf2.h)
On 2018-08-23 13:35, John Darrington wrote:
* include/dwarf2.h (enum dwarf_unit_type)[DW_EH_PE_udata3]: New member.
* gdb/dwarf2-frame.c (encoding_for_size): Deal with case 3.
(read_encoded_value): Deal with case
On 2018-08-02 13:44, Tom Tromey wrote:
"Simon" == Simon Marchi writes:
Simon> intl/ChangeLog:
Simon> * libgnuintl.h (_INTL_MAY_RETURN_STRING_ARG, gettext, dgettext,
Simon> dcgettext, ngettext, dngettext, dcngettext): Backport changes
Simon> from upstre
On 2018-08-01 10:58, Simon Marchi wrote:
This patch was tested to build binutils-gdb on GNU/Linux and macOS. It
can be
applied to the gcc repo too, after fixing some trivial merge conflicts
(someone
else will need to do it, as I don't have push access to gcc). Although
I think
This patch was tested to build binutils-gdb on GNU/Linux and macOS. It can be
applied to the gcc repo too, after fixing some trivial merge conflicts (someone
else will need to do it, as I don't have push access to gcc). Although I think
it is relatively low-risk, building gcc on macOS was not
37 matches
Mail list logo
