Re: [PATCH] libgm2: re-generate with autoreconf
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 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 >>> >>> Running "autoreconf" uses the latter order, so I think that's the >>> "right" output. >>> >>> No functional difference expected. >> >> Thanks, this matches what I noticed. >> I'm not a maintainer, so I cannot approve, but a minor remark: in GCC >> we still need a ChangeLog entry in the commit message. >> >> Christophe > > many thanks for spotting this bug, lgtm, > > regards, > Gaius Here is the ChangeLog entry: libgm2/ChangeLog: * Makefile.in, aclocal.m4, libm2cor/Makefile.in, libm2iso/Makefile.in, libm2log/Makefile.in, libm2min/Makefile.in, libm2pim/Makefile.in: Re-generate. I don't have access to the gcc repo, so could you please push the patch on my behalf? Thanks, Simon
Re: [PATCH] fixincludes: add AC_CONFIG_MACRO_DIRS to configure.ac
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. >> >> This makes it possible to re-generate aclocal.m4 using "autoreconf". > > Thanks, this LGTM, although like in your other patch, we need a > ChangeLog entry in the commit message. > > Christophe Here is the ChangeLog entry: fixincludes/ChangeLog: * configure.ac: Add AC_CONFIG_MACRO_DIRS. * configure: Re-generate. I don't have access to the gcc repo, so if/when this patch gets approved, can you push it on my behalf? Thanks, Simon
[PATCH] fixincludes: add AC_CONFIG_MACRO_DIRS to configure.ac
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 insertions(+) diff --git a/fixincludes/configure b/fixincludes/configure index 662c94dc1120..7147c9a618aa 100755 --- a/fixincludes/configure +++ b/fixincludes/configure @@ -4627,6 +4627,7 @@ $as_echo "$ac_cv_path_SED" >&6; } rm -f conftest.sed + # Figure out what compiler warnings we can enable. # See config/warnings.m4 for details. diff --git a/fixincludes/configure.ac b/fixincludes/configure.ac index 4e78511d20fc..3d177699ebfa 100644 --- a/fixincludes/configure.ac +++ b/fixincludes/configure.ac @@ -7,6 +7,7 @@ AC_CANONICAL_SYSTEM AC_PROG_CC AC_USE_SYSTEM_EXTENSIONS AC_PROG_SED +AC_CONFIG_MACRO_DIRS([.. ../config]) # Figure out what compiler warnings we can enable. # See config/warnings.m4 for details. base-commit: 22b20ac6c6aead2d3f36c413a77dd0b80adfec39 -- 2.44.0
[PATCH] libgm2: re-generate with autoreconf
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 Running "autoreconf" uses the latter order, so I think that's the "right" output. No functional difference expected. --- libgm2/Makefile.in | 10 +- libgm2/aclocal.m4 | 10 +- libgm2/libm2cor/Makefile.in | 10 +- libgm2/libm2iso/Makefile.in | 10 +- libgm2/libm2log/Makefile.in | 10 +- libgm2/libm2min/Makefile.in | 10 +- libgm2/libm2pim/Makefile.in | 10 +- 7 files changed, 35 insertions(+), 35 deletions(-) diff --git a/libgm2/Makefile.in b/libgm2/Makefile.in index f259df7842cf..9cd79824a53d 100644 --- a/libgm2/Makefile.in +++ b/libgm2/Makefile.in @@ -90,15 +90,15 @@ host_triplet = @host@ target_triplet = @target@ subdir = . ACLOCAL_M4 = $(top_srcdir)/aclocal.m4 -am__aclocal_m4_deps = $(top_srcdir)/../libtool.m4 \ - $(top_srcdir)/../ltoptions.m4 $(top_srcdir)/../ltsugar.m4 \ - $(top_srcdir)/../ltversion.m4 $(top_srcdir)/../lt~obsolete.m4 \ - $(top_srcdir)/../config/acx.m4 \ +am__aclocal_m4_deps = $(top_srcdir)/../config/acx.m4 \ $(top_srcdir)/../config/depstand.m4 \ $(top_srcdir)/../config/lead-dot.m4 \ $(top_srcdir)/../config/multi.m4 \ $(top_srcdir)/../config/no-executables.m4 \ - $(top_srcdir)/../config/override.m4 $(top_srcdir)/acinclude.m4 \ + $(top_srcdir)/../config/override.m4 \ + $(top_srcdir)/../libtool.m4 $(top_srcdir)/../ltoptions.m4 \ + $(top_srcdir)/../ltsugar.m4 $(top_srcdir)/../ltversion.m4 \ + $(top_srcdir)/../lt~obsolete.m4 $(top_srcdir)/acinclude.m4 \ $(top_srcdir)/../config/gc++filt.m4 \ $(top_srcdir)/../config/tls.m4 $(top_srcdir)/../config/gthr.m4 \ $(top_srcdir)/../config/cet.m4 $(top_srcdir)/configure.ac diff --git a/libgm2/aclocal.m4 b/libgm2/aclocal.m4 index bee67b05dee2..19cfb0d1eb26 100644 --- a/libgm2/aclocal.m4 +++ b/libgm2/aclocal.m4 @@ -1187,15 +1187,15 @@ AC_SUBST([am__tar]) AC_SUBST([am__untar]) ]) # _AM_PROG_TAR -m4_include([../libtool.m4]) -m4_include([../ltoptions.m4]) -m4_include([../ltsugar.m4]) -m4_include([../ltversion.m4]) -m4_include([../lt~obsolete.m4]) m4_include([../config/acx.m4]) m4_include([../config/depstand.m4]) m4_include([../config/lead-dot.m4]) m4_include([../config/multi.m4]) m4_include([../config/no-executables.m4]) m4_include([../config/override.m4]) +m4_include([../libtool.m4]) +m4_include([../ltoptions.m4]) +m4_include([../ltsugar.m4]) +m4_include([../ltversion.m4]) +m4_include([../lt~obsolete.m4]) m4_include([acinclude.m4]) diff --git a/libgm2/libm2cor/Makefile.in b/libgm2/libm2cor/Makefile.in index 63299388dd8f..f9952cff71a7 100644 --- a/libgm2/libm2cor/Makefile.in +++ b/libgm2/libm2cor/Makefile.in @@ -108,15 +108,15 @@ target_triplet = @target@ @BUILD_CORLIB_TRUE@@ENABLE_DARWIN_AT_RPATH_TRUE@am__append_1 = -nodefaultrpaths -Wl,-rpath,@loader_path/ subdir = libm2cor ACLOCAL_M4 = $(top_srcdir)/aclocal.m4 -am__aclocal_m4_deps = $(top_srcdir)/../libtool.m4 \ - $(top_srcdir)/../ltoptions.m4 $(top_srcdir)/../ltsugar.m4 \ - $(top_srcdir)/../ltversion.m4 $(top_srcdir)/../lt~obsolete.m4 \ - $(top_srcdir)/../config/acx.m4 \ +am__aclocal_m4_deps = $(top_srcdir)/../config/acx.m4 \ $(top_srcdir)/../config/depstand.m4 \ $(top_srcdir)/../config/lead-dot.m4 \ $(top_srcdir)/../config/multi.m4 \ $(top_srcdir)/../config/no-executables.m4 \ - $(top_srcdir)/../config/override.m4 $(top_srcdir)/acinclude.m4 \ + $(top_srcdir)/../config/override.m4 \ + $(top_srcdir)/../libtool.m4 $(top_srcdir)/../ltoptions.m4 \ + $(top_srcdir)/../ltsugar.m4 $(top_srcdir)/../ltversion.m4 \ + $(top_srcdir)/../lt~obsolete.m4 $(top_srcdir)/acinclude.m4 \ $(top_srcdir)/../config/gc++filt.m4 \ $(top_srcdir)/../config/tls.m4 $(top_srcdir)/../config/gthr.m4 \ $(top_srcdir)/../config/cet.m4 $(top_srcdir)/configure.ac diff --git a/libgm2/libm2iso/Makefile.in b/libgm2/libm2iso/Makefile.in index 964c6da85270..370837f15b82 100644 --- a/libgm2/libm2iso/Makefile.in +++ b/libgm2/libm2iso/Makefile.in @@ -108,15 +108,15 @@ target_triplet = @target@ @BUILD_ISOLIB_TRUE@@ENABLE_DARWIN_AT_RPATH_TRUE@am__append_1 = -nodefaultrpaths -Wl,-rpath,@loader_path/ subdir = libm2iso ACLOCAL_M4 = $(top_srcdir)/aclocal.m4 -am__aclocal_m4_deps = $(top_srcdir)/../libtool.m4 \ - $(top_srcdir)/../ltoptions.m4 $(top_srcdir)/../ltsugar.m4 \ - $(top_srcdir)/../ltversion.m4 $(top_srcdir)/../lt~obsolete.m4 \ - $(top_srcdir)/../config/acx.m4 \ +am__aclocal_m4_deps = $(top_srcdir)/../config/acx.m4 \ $(top_srcdir)/../config/depstand.m4 \ $(top_srcdir)/../config/lead-dot.m4 \
Re: [PATCH] Pass PKG_CONFIG_PATH down from top-level Makefile
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: > 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 it during > configure: > > $ PKG_CONFIG_PATH=/opt/debuginfod/lib/pkg-config ./configure > --with-debuginfod > $ make > > or > > $ ./configure --with-debuginfod > PKG_CONFIG_PATH=/opt/debuginfod/lib/pkg-config > $ make > > Then PKG_CONFIG_PATH is only present (and ignored) during the top-level > configure. When running make (which runs gdb's and binutils' > configure), PKG_CONFIG_PATH is not set, which results in their configure > script not finding the library: > > checking for libdebuginfod >= 0.179... no > configure: error: "--with-debuginfod was given, but libdebuginfod is > missing or unusable." > > Change the top-level configure/Makefile system to capture the value > passed when configuring the top-level and pass it down to > subdirectories (similar to CFLAGS, LDFLAGS, etc). > > I don't know much about the top-level build system, so I really don't > know if I did this correctly. The changes are: > > - Use AC_SUBST(PKG_CONFIG_PATH) in configure.ac, so that >@PKG_CONFIG_PATH@ gets replaced with the actual PKG_CONFIG_PATH value >in config files (i.e. Makefile) > - Add a PKG_CONFIG_PATH Makefile variable in Makefile.tpl, initialized >to @PKG_CONFIG_PATH@ > - Add PKG_CONFIG_PATH to HOST_EXPORTS in Makefile.tpl, which are the >variables set when running the sub-configures > > I initially added PKG_CONFIG_PATH to flags_to_pass, in Makefile.def, but > I don't think it's needed. AFAIU, this defines the flags to pass down > when calling "make" in subdirectories. We only need PKG_CONFIG_PATH to > be passed down during configure. After that, it's captured in > gdb/config.status, so even if a "make" causes a re-configure later > (because gdb/configure has changed, for example), the PKG_CONFIG_PATH > value will be remembered. > > ChangeLog: > > * configure.ac: Add AC_SUBST(PKG_CONFIG_PATH). > * configure: Re-generate. > * Makefile.tpl (HOST_EXPORTS): Pass PKG_CONFIG_PATH. > (PKG_CONFIG_PATH): New. > * Makefile.in: Re-generate. > > Change-Id: I91138dfca41c43b05e53e445f62e4b27882536bf > --- > Makefile.in | 3 +++ > Makefile.tpl | 3 +++ > configure| 2 ++ > configure.ac | 1 + > 4 files changed, 9 insertions(+) > > diff --git a/Makefile.in b/Makefile.in > index 3aacd2daac9c..cb39e4790d69 100644 > --- a/Makefile.in > +++ b/Makefile.in > @@ -218,6 +218,7 @@ HOST_EXPORTS = \ > OBJCOPY="$(OBJCOPY)"; export OBJCOPY; \ > OBJDUMP="$(OBJDUMP)"; export OBJDUMP; \ > OTOOL="$(OTOOL)"; export OTOOL; \ > + PKG_CONFIG_PATH="$(PKG_CONFIG_PATH)"; export PKG_CONFIG_PATH; \ > READELF="$(READELF)"; export READELF; \ > AR_FOR_TARGET="$(AR_FOR_TARGET)"; export AR_FOR_TARGET; \ > AS_FOR_TARGET="$(AS_FOR_TARGET)"; export AS_FOR_TARGET; \ > @@ -444,6 +445,8 @@ LIBCXXFLAGS = $(CXXFLAGS) -fno-implicit-templates > GOCFLAGS = $(CFLAGS) > GDCFLAGS = $(CFLAGS) > > +PKG_CONFIG_PATH = @PKG_CONFIG_PATH@ > + > # Pass additional PGO and LTO compiler options to the PGO build. > BUILD_CFLAGS = $(PGO_BUILD_CFLAGS) $(PGO_BUILD_LTO_CFLAGS) > override CFLAGS += $(BUILD_CFLAGS) > diff --git a/Makefile.tpl b/Makefile.tpl > index 9df77788345a..88db8f44d53f 100644 > --- a/Makefile.tpl > +++ b/Makefile.tpl > @@ -221,6 +221,7 @@ HOST_EXPORTS = \ > OBJCOPY="$(OBJCOPY)"; export OBJCOPY; \ > OBJDUMP="$(OBJDUMP)"; export OBJDUMP; \ > OTOOL="$(OTOOL)"; export OTOOL; \ > + PKG_CONFIG_PATH="$(PKG_CONFIG_PATH)"; export PKG_CONFIG_PATH; \ > READELF="$(READELF)"; export READELF; \ > AR_FOR_TARGET="$(AR_FOR_TARGET)"; export AR_FOR_TARGET; \ > AS_FOR_TARGET="$(AS_FOR_TARGET)"; export AS_FOR_TARGET; \ > @@ -447,6 +448,8 @@ LIBCXXFLAGS = $(CXXFLAGS) -fno-implicit-templates > GOCFLAGS = $(CFLAGS) > GDCFLAGS = $(CFLAGS) > > +PKG_CONFIG_PATH = @PKG_CONFIG_PATH@ > + > # Pass additional PGO and LTO compiler
[PATCH] libiberty: add AC_CONFIG_MACRO_DIRS
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. libiberty/ChangeLog: * configure.ac: Add AC_CONFIG_MACRO_DIRS call. * configure: Re-generate. Change-Id: Ic600481d03b36c95aacc555300b78d9cc0ef06bc --- libiberty/configure| 1 + libiberty/configure.ac | 1 + 2 files changed, 2 insertions(+) diff --git a/libiberty/configure b/libiberty/configure index e09ddd91e584..306c07bd37e9 100755 --- a/libiberty/configure +++ b/libiberty/configure @@ -2461,6 +2461,7 @@ ac_compiler_gnu=$ac_cv_c_compiler_gnu + # This works around the fact that libtool configuration may change LD # for this particular configuration, but some shells, instead of # keeping the changes in LD private, export them just because LD is diff --git a/libiberty/configure.ac b/libiberty/configure.ac index f59f35e1f208..6c1ff9c60933 100644 --- a/libiberty/configure.ac +++ b/libiberty/configure.ac @@ -2,6 +2,7 @@ dnl Process this file with autoconf to produce a configure script AC_INIT AC_CONFIG_SRCDIR([xmalloc.c]) +AC_CONFIG_MACRO_DIRS([../config]) # This works around the fact that libtool configuration may change LD # for this particular configuration, but some shells, instead of -- 2.26.2
Re: [PATCH] Pass PKG_CONFIG_PATH down from top-level Makefile
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
Re: [PATCH] Pass PKG_CONFIG_PATH down from top-level Makefile
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 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 it during >> configure: >> >> $ PKG_CONFIG_PATH=/opt/debuginfod/lib/pkg-config ./configure >> --with-debuginfod >> $ make >> >> or >> >> $ ./configure --with-debuginfod >> PKG_CONFIG_PATH=/opt/debuginfod/lib/pkg-config >> $ make >> >> Then PKG_CONFIG_PATH is only present (and ignored) during the top-level >> configure. When running make (which runs gdb's and binutils' >> configure), PKG_CONFIG_PATH is not set, which results in their configure >> script not finding the library: >> >> checking for libdebuginfod >= 0.179... no >> configure: error: "--with-debuginfod was given, but libdebuginfod is >> missing or unusable." >> >> Change the top-level configure/Makefile system to capture the value >> passed when configuring the top-level and pass it down to >> subdirectories (similar to CFLAGS, LDFLAGS, etc). >> >> I don't know much about the top-level build system, so I really don't >> know if I did this correctly. The changes are: >> >> - Use AC_SUBST(PKG_CONFIG_PATH) in configure.ac, so that >>@PKG_CONFIG_PATH@ gets replaced with the actual PKG_CONFIG_PATH value >>in config files (i.e. Makefile) >> - Add a PKG_CONFIG_PATH Makefile variable in Makefile.tpl, initialized >>to @PKG_CONFIG_PATH@ >> - Add PKG_CONFIG_PATH to HOST_EXPORTS in Makefile.tpl, which are the >>variables set when running the sub-configures >> >> I initially added PKG_CONFIG_PATH to flags_to_pass, in Makefile.def, but >> I don't think it's needed. AFAIU, this defines the flags to pass down >> when calling "make" in subdirectories. We only need PKG_CONFIG_PATH to >> be passed down during configure. After that, it's captured in >> gdb/config.status, so even if a "make" causes a re-configure later >> (because gdb/configure has changed, for example), the PKG_CONFIG_PATH >> value will be remembered. >> >> ChangeLog: >> >> * configure.ac: Add AC_SUBST(PKG_CONFIG_PATH). >> * configure: Re-generate. >> * Makefile.tpl (HOST_EXPORTS): Pass PKG_CONFIG_PATH. >> (PKG_CONFIG_PATH): New. >> * Makefile.in: Re-generate. >> >> Change-Id: I91138dfca41c43b05e53e445f62e4b27882536bf >> --- >> Makefile.in | 3 +++ >> Makefile.tpl | 3 +++ >> configure| 2 ++ >> configure.ac | 1 + >> 4 files changed, 9 insertions(+) >> >> diff --git a/Makefile.in b/Makefile.in >> index 3aacd2daac9c..cb39e4790d69 100644 >> --- a/Makefile.in >> +++ b/Makefile.in >> @@ -218,6 +218,7 @@ HOST_EXPORTS = \ >> OBJCOPY="$(OBJCOPY)"; export OBJCOPY; \ >> OBJDUMP="$(OBJDUMP)"; export OBJDUMP; \ >> OTOOL="$(OTOOL)"; export OTOOL; \ >> +PKG_CONFIG_PATH="$(PKG_CONFIG_PATH)"; export PKG_CONFIG_PATH; \ >> READELF="$(READELF)"; export READELF; \ >> AR_FOR_TARGET="$(AR_FOR_TARGET)"; export AR_FOR_TARGET; \ >> AS_FOR_TARGET="$(AS_FOR_TARGET)"; export AS_FOR_TARGET; \ >> @@ -444,6 +445,8 @@ LIBCXXFLAGS = $(CXXFLAGS) -fno-implicit-templates >> GOCFLAGS = $(CFLAGS) >> GDCFLAGS = $(CFLAGS) >> >> +PKG_CONFIG_PATH = @PKG_CONFIG_PATH@ >> + >> # Pass additional PGO and LTO compiler options to the PGO build. >> BUILD_CFLAGS = $(PGO_BUILD_CFLAGS) $(PGO_BUILD_LTO_CFLAGS) >> override CFLAGS += $(BUILD_CFLAGS) >> diff --git a/Makefile.tpl b/Makefile.tpl >> index 9df77788345a..88db8f44d53f 100644 >> --- a/Makefile.tpl >> +++ b/Makefile.tpl >> @@ -221,6 +221,7 @@ HOST_EXPORTS = \ >> OBJCOPY="$(OBJCOPY)"; export OBJCOPY; \ >> OBJDUMP="$(OBJDUMP)"; export OBJDUMP; \ >> OTOOL="$(OTOOL)"; export OTOOL; \ >> +PKG_CONFIG_PATH="$(PKG_CONFIG_PATH)"; export PKG_CONFIG_PATH; \ >> READELF="$(READELF)"; export READELF; \ >> AR_FOR_TARGET="$(AR_FOR_TARGET)"; export AR_FOR_TARGET; \ >> AS_FOR_TARGET="$(AS_FOR_TARGET)"; export AS_FOR_TARGET; \ >> @@ -447,6 +448,8 @@ LIBCXX
Re: [PATCH] Pass PKG_CONFIG_PATH down from top-level Makefile
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), which requires me to set > PKG_CONFIG_PATH=/opt/debuginfod/lib/pkg-config. If I just set it during > configure: > > $ PKG_CONFIG_PATH=/opt/debuginfod/lib/pkg-config ./configure > --with-debuginfod > $ make > > or > > $ ./configure --with-debuginfod > PKG_CONFIG_PATH=/opt/debuginfod/lib/pkg-config > $ make > > Then PKG_CONFIG_PATH is only present (and ignored) during the top-level > configure. When running make (which runs gdb's and binutils' > configure), PKG_CONFIG_PATH is not set, which results in their configure > script not finding the library: > > checking for libdebuginfod >= 0.179... no > configure: error: "--with-debuginfod was given, but libdebuginfod is > missing or unusable." > > Change the top-level configure/Makefile system to capture the value > passed when configuring the top-level and pass it down to > subdirectories (similar to CFLAGS, LDFLAGS, etc). > > I don't know much about the top-level build system, so I really don't > know if I did this correctly. The changes are: > > - Use AC_SUBST(PKG_CONFIG_PATH) in configure.ac, so that >@PKG_CONFIG_PATH@ gets replaced with the actual PKG_CONFIG_PATH value >in config files (i.e. Makefile) > - Add a PKG_CONFIG_PATH Makefile variable in Makefile.tpl, initialized >to @PKG_CONFIG_PATH@ > - Add PKG_CONFIG_PATH to HOST_EXPORTS in Makefile.tpl, which are the >variables set when running the sub-configures > > I initially added PKG_CONFIG_PATH to flags_to_pass, in Makefile.def, but > I don't think it's needed. AFAIU, this defines the flags to pass down > when calling "make" in subdirectories. We only need PKG_CONFIG_PATH to > be passed down during configure. After that, it's captured in > gdb/config.status, so even if a "make" causes a re-configure later > (because gdb/configure has changed, for example), the PKG_CONFIG_PATH > value will be remembered. > > ChangeLog: > > * configure.ac: Add AC_SUBST(PKG_CONFIG_PATH). > * configure: Re-generate. > * Makefile.tpl (HOST_EXPORTS): Pass PKG_CONFIG_PATH. > (PKG_CONFIG_PATH): New. > * Makefile.in: Re-generate. > > Change-Id: I91138dfca41c43b05e53e445f62e4b27882536bf > --- > Makefile.in | 3 +++ > Makefile.tpl | 3 +++ > configure| 2 ++ > configure.ac | 1 + > 4 files changed, 9 insertions(+) > > diff --git a/Makefile.in b/Makefile.in > index 3aacd2daac9c..cb39e4790d69 100644 > --- a/Makefile.in > +++ b/Makefile.in > @@ -218,6 +218,7 @@ HOST_EXPORTS = \ > OBJCOPY="$(OBJCOPY)"; export OBJCOPY; \ > OBJDUMP="$(OBJDUMP)"; export OBJDUMP; \ > OTOOL="$(OTOOL)"; export OTOOL; \ > + PKG_CONFIG_PATH="$(PKG_CONFIG_PATH)"; export PKG_CONFIG_PATH; \ > READELF="$(READELF)"; export READELF; \ > AR_FOR_TARGET="$(AR_FOR_TARGET)"; export AR_FOR_TARGET; \ > AS_FOR_TARGET="$(AS_FOR_TARGET)"; export AS_FOR_TARGET; \ > @@ -444,6 +445,8 @@ LIBCXXFLAGS = $(CXXFLAGS) -fno-implicit-templates > GOCFLAGS = $(CFLAGS) > GDCFLAGS = $(CFLAGS) > > +PKG_CONFIG_PATH = @PKG_CONFIG_PATH@ > + > # Pass additional PGO and LTO compiler options to the PGO build. > BUILD_CFLAGS = $(PGO_BUILD_CFLAGS) $(PGO_BUILD_LTO_CFLAGS) > override CFLAGS += $(BUILD_CFLAGS) > diff --git a/Makefile.tpl b/Makefile.tpl > index 9df77788345a..88db8f44d53f 100644 > --- a/Makefile.tpl > +++ b/Makefile.tpl > @@ -221,6 +221,7 @@ HOST_EXPORTS = \ > OBJCOPY="$(OBJCOPY)"; export OBJCOPY; \ > OBJDUMP="$(OBJDUMP)"; export OBJDUMP; \ > OTOOL="$(OTOOL)"; export OTOOL; \ > + PKG_CONFIG_PATH="$(PKG_CONFIG_PATH)"; export PKG_CONFIG_PATH; \ > READELF="$(READELF)"; export READELF; \ > AR_FOR_TARGET="$(AR_FOR_TARGET)"; export AR_FOR_TARGET; \ > AS_FOR_TARGET="$(AS_FOR_TARGET)"; export AS_FOR_TARGET; \ > @@ -447,6 +448,8 @@ LIBCXXFLAGS = $(CXXFLAGS) -fno-implicit-templates > GOCFLAGS = $(CFLAGS) > GDCFLAGS = $(CFLAGS) > > +PKG_CONFIG_PATH = @PKG_CONFIG_PATH@ > + > # Pass additional PGO and LTO compiler options to the PGO build. > BUILD_CFLAGS = $(PGO_BUILD_CFLAGS) $(PGO_BUILD_LTO_CFLAGS) > override CFLAGS += $(BUILD_CFLAGS) > diff --git a/configure b/configure > index 26935ebda249..1badcb314f8f 100755 > --- a/configure
[PATCH] Pass PKG_CONFIG_PATH down from top-level Makefile
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 it during
configure:
$ PKG_CONFIG_PATH=/opt/debuginfod/lib/pkg-config ./configure
--with-debuginfod
$ make
or
$ ./configure --with-debuginfod
PKG_CONFIG_PATH=/opt/debuginfod/lib/pkg-config
$ make
Then PKG_CONFIG_PATH is only present (and ignored) during the top-level
configure. When running make (which runs gdb's and binutils'
configure), PKG_CONFIG_PATH is not set, which results in their configure
script not finding the library:
checking for libdebuginfod >= 0.179... no
configure: error: "--with-debuginfod was given, but libdebuginfod is
missing or unusable."
Change the top-level configure/Makefile system to capture the value
passed when configuring the top-level and pass it down to
subdirectories (similar to CFLAGS, LDFLAGS, etc).
I don't know much about the top-level build system, so I really don't
know if I did this correctly. The changes are:
- Use AC_SUBST(PKG_CONFIG_PATH) in configure.ac, so that
@PKG_CONFIG_PATH@ gets replaced with the actual PKG_CONFIG_PATH value
in config files (i.e. Makefile)
- Add a PKG_CONFIG_PATH Makefile variable in Makefile.tpl, initialized
to @PKG_CONFIG_PATH@
- Add PKG_CONFIG_PATH to HOST_EXPORTS in Makefile.tpl, which are the
variables set when running the sub-configures
I initially added PKG_CONFIG_PATH to flags_to_pass, in Makefile.def, but
I don't think it's needed. AFAIU, this defines the flags to pass down
when calling "make" in subdirectories. We only need PKG_CONFIG_PATH to
be passed down during configure. After that, it's captured in
gdb/config.status, so even if a "make" causes a re-configure later
(because gdb/configure has changed, for example), the PKG_CONFIG_PATH
value will be remembered.
ChangeLog:
* configure.ac: Add AC_SUBST(PKG_CONFIG_PATH).
* configure: Re-generate.
* Makefile.tpl (HOST_EXPORTS): Pass PKG_CONFIG_PATH.
(PKG_CONFIG_PATH): New.
* Makefile.in: Re-generate.
Change-Id: I91138dfca41c43b05e53e445f62e4b27882536bf
---
Makefile.in | 3 +++
Makefile.tpl | 3 +++
configure| 2 ++
configure.ac | 1 +
4 files changed, 9 insertions(+)
diff --git a/Makefile.in b/Makefile.in
index 3aacd2daac9c..cb39e4790d69 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -218,6 +218,7 @@ HOST_EXPORTS = \
OBJCOPY="$(OBJCOPY)"; export OBJCOPY; \
OBJDUMP="$(OBJDUMP)"; export OBJDUMP; \
OTOOL="$(OTOOL)"; export OTOOL; \
+ PKG_CONFIG_PATH="$(PKG_CONFIG_PATH)"; export PKG_CONFIG_PATH; \
READELF="$(READELF)"; export READELF; \
AR_FOR_TARGET="$(AR_FOR_TARGET)"; export AR_FOR_TARGET; \
AS_FOR_TARGET="$(AS_FOR_TARGET)"; export AS_FOR_TARGET; \
@@ -444,6 +445,8 @@ LIBCXXFLAGS = $(CXXFLAGS) -fno-implicit-templates
GOCFLAGS = $(CFLAGS)
GDCFLAGS = $(CFLAGS)
+PKG_CONFIG_PATH = @PKG_CONFIG_PATH@
+
# Pass additional PGO and LTO compiler options to the PGO build.
BUILD_CFLAGS = $(PGO_BUILD_CFLAGS) $(PGO_BUILD_LTO_CFLAGS)
override CFLAGS += $(BUILD_CFLAGS)
diff --git a/Makefile.tpl b/Makefile.tpl
index 9df77788345a..88db8f44d53f 100644
--- a/Makefile.tpl
+++ b/Makefile.tpl
@@ -221,6 +221,7 @@ HOST_EXPORTS = \
OBJCOPY="$(OBJCOPY)"; export OBJCOPY; \
OBJDUMP="$(OBJDUMP)"; export OBJDUMP; \
OTOOL="$(OTOOL)"; export OTOOL; \
+ PKG_CONFIG_PATH="$(PKG_CONFIG_PATH)"; export PKG_CONFIG_PATH; \
READELF="$(READELF)"; export READELF; \
AR_FOR_TARGET="$(AR_FOR_TARGET)"; export AR_FOR_TARGET; \
AS_FOR_TARGET="$(AS_FOR_TARGET)"; export AS_FOR_TARGET; \
@@ -447,6 +448,8 @@ LIBCXXFLAGS = $(CXXFLAGS) -fno-implicit-templates
GOCFLAGS = $(CFLAGS)
GDCFLAGS = $(CFLAGS)
+PKG_CONFIG_PATH = @PKG_CONFIG_PATH@
+
# Pass additional PGO and LTO compiler options to the PGO build.
BUILD_CFLAGS = $(PGO_BUILD_CFLAGS) $(PGO_BUILD_LTO_CFLAGS)
override CFLAGS += $(BUILD_CFLAGS)
diff --git a/configure b/configure
index 26935ebda249..1badcb314f8f 100755
--- a/configure
+++ b/configure
@@ -618,6 +618,7 @@ CXX_FOR_TARGET
CC_FOR_TARGET
RANLIB_PLUGIN_OPTION
AR_PLUGIN_OPTION
+PKG_CONFIG_PATH
READELF
OBJDUMP
OBJCOPY
@@ -10310,6 +10311,7 @@ fi
+
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for -plugin option" >&5
$as_echo_n "checking for -plugin option... " >&6; }
diff --git a/configure.ac b/configure.ac
index da4e41d72479..5b6e20485143 100644
--- a/configure.ac
+++ b/configure.ac
@@ -3465,6 +3465,7 @@ AC_SUBST(CC)
AC_SUBST(CXX)
AC_SUBST(CFLAGS)
AC_SUBST(CXXFLAGS)
+AC_SUBST(PKG_CONFIG_PATH)
GCC_PLUGIN_OPTION(PLUGIN_OPTION)
AR_PLUGIN_OPTION=
base-commit: 6aa03e9c1769c8d925f4d23d72af93483bfd31f3
--
2.35.1
Re: RFC: Changing AC_PROG_CC to AC_PROG_CC_C99 in top level configure
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 repositories. > > Cheers > Nick > Thanks Nick! Simon
Re: RFC: Changing AC_PROG_CC to AC_PROG_CC_C99 in top level configure
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 "make check" sometimes in a > subdir expecting to get the same results in that subdir as if "make > check" was run from the top level. Ah yeah, that works just fine. During my edit-build-cycle, I typically only "make" in gdb/, or whatever I'm working on at the moment. It saves some precious milliseconds! > But I should have just tried it myself rather than asking. CC, CPP > and others are inherited from the top level and appear with -std=gnu99 > in the subdir Makefiles. So it seems all the AC_PROG_CC in subdir > configure.ac can stay as they are. Yes, the top-level passes CC=... and others when it configures the subdirectories. The subdirectories remember how they were configures (in config.status), so that even if a "make" in the subdirectory ends up re-running configure (because configure changed), the CC value will be remembered. Simon
Re: RFC: Changing AC_PROG_CC to AC_PROG_CC_C99 in top level configure
> 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 not supported to run gdb/configure directly, you need to use the top-level configure. Is it supported from some of the other projects in the repo? I just tried with ld, it doesn't work since it depends on bfd also being built. I tried with just bfd, it doesn't work (with the default configure options at least) because it requires zlib being built. So if all projects need to go through the top-level configure script anyway, and C99 is a baseline for all projects, then having the check only in the top-level makes sense to me. Projects that have more specific requirements can have their own checks. For example, sim/ requires C11 now. Unless the C99 check at top-level somehow does not play well with the C11 check in sim/? Like if that would cause CC to be set to "gcc -std=gnu99 -std=gnu11" or something like that. Simon
Re: RFC: Changing AC_PROG_CC to AC_PROG_CC_C99 in top level configure
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 b/configure.ac > index a721316d07b..59b4194fb24 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -1278,7 +1278,7 @@ else >WINDMC_FOR_BUILD="\$(WINDMC)" > fi > > -AC_PROG_CC > +AC_PROG_CC_C99 > AC_PROG_CXX > > # We must set the default linker to the linker used by gcc for the correct Hi Nick, I think this fix is obvious enough, I encourage you to push it, that will fix the build failure many people get in opcodes/ppc-dis.c. We'll just remove the line later when we upgrade to Autoconf 2.71, as simple as that. For now we use 2.69. If that matters, you have my OK for the GDB side of things. Simon
[PATCH] Sync .gitignore with binutils-gdb
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(+) diff --git a/.gitignore b/.gitignore index 1a29029895aa..382e2def731e 100644 --- a/.gitignore +++ b/.gitignore @@ -15,6 +15,7 @@ *.o *.pyc *.tmp +*.a .deps .libs @@ -44,6 +45,9 @@ compile_commands.json .gdbinit .gdb_history +perf.data +perf.data.old + # ignore core files, but not java/net/protocol/core/ core !core/ @@ -54,6 +58,9 @@ lost+found LAST_UPDATED REVISION +stamp-* +*.stamp + # ignore in-tree prerequisites /mpfr* /mpc* -- 2.29.2
Split DWARF and rnglists, gcc vs clang
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 one of them is not doing things correctly and would need to be fixed. clang generates a .debug_rnglists.dwo section in the .dwo file. Any DW_FORM_rnglistx attribute in the DWO refers to that section. That section is not shared with any other object, so DW_AT_rnglists_base is never involved for these attributes. Note that there might still be a DW_AT_rnglists_base on the DW_TAG_skeleton_unit, in the linked file, used if the skeleton itself has an attribute of form DW_FORM_rnglistx. This rnglist would be found in a .debug_rnglists section in the linked file, shared with the other units of the linked file. gcc generates a single .debug_rnglists in the linked file and no .debug_rnglists.dwo in the DWO files. So when an attribute has form DW_FORM_rnglistx in a DWO file, I presume we need to do the lookup in the .debug_rnglists section in the linked file, using the DW_AT_rnglists_base attribute found in the corresponding skeleton unit. This looks vaguely similar to how it was done pre-DWARF 5, with DW_AT_GNU_ranges base. So, is gcc wrong here? I don't see anything in the DWARF 5 spec prohibiting to do it like gcc does, but clang's way of doing it sounds more in-line with the intent of what's described in the DWARF 5 spec. So I wonder if it's maybe an oversight or a misunderstanding between the two compilers. But if both ways are correct, then we just need to know so we can implement it in GDB. Although we'll probably need to implement reading what gcc currently produces, since it's already in the wild. Simon
Re: V2 [PATCH] PKG_CHECK_MODULES: Check if $pkg_cv_[]$1[]_LIBS works
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 an optional (only needed when >> enabling support for libdebuginfod) *build* dependency on a quite standard >> tool. That's not very demanding. >> >> If you don't want to deal with libdebuginfod, you can also just build with >> --without-debuginfod. > > My binutils script had been working fine until pkg.m4 was added Ok but... that doesn't mean anything. I think we made it quite clear that the issue is with your build environment, not the build system (pkg.m4). >Can it be moved to gdb directory? It can, but I don't think it would be a good idea. It would just be confusing for binutils and GDB to both use libdebuginfod but use different methods of finding it. Somebody building binutils + GDB with libdebuginfod support against a libdebuginfod in a non-default location would have to specify the location of the library in two different ways. Simon
Re: V2 [PATCH] PKG_CHECK_MODULES: Check if $pkg_cv_[]$1[]_LIBS works
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 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 properly for cross-compiling. > > Since when binutils can't fix issues in other packages? Like I said, we can make local changes if necessary, to fix issues. But there is no issue to fix here, all is needed is to have a proper build environment. Doing an unnecessary local change just adds burden on the next person who will sync this file with upstream, so it should not be taken lightly. > 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 an optional (only needed when enabling support for libdebuginfod) *build* dependency on a quite standard tool. That's not very demanding. If you don't want to deal with libdebuginfod, you can also just build with --without-debuginfod. Simon
Re: V2 [PATCH] PKG_CHECK_MODULES: Check if $pkg_cv_[]$1[]_LIBS works
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 properly for cross-compiling. (2) I don't think it's necessarily bad to try to do a link to confirm the lib is indeed there, but as I said earlier I don't think that doing as if the package was not there is the right response. This can happen if you have a mis-configured pkg-config (like you have) or a broken installation (for example, the .pc is there but the lib is not). In either case, there's something wrong with the build environment and I think it's more useful to abort and tell the user rather than silently failing. Point 2 should be discussed upstream anyway, there's no point making a decision local to binutils-gdb. Simon
Re: V2 [PATCH] PKG_CHECK_MODULES: Check if $pkg_cv_[]$1[]_LIBS works
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 -m32" CXX="g++ -m32" >> checking build system type... x86_64-pc-linux-gnu >> checking host system type... x86_64-pc-linux-gnu >> checking target system type... x86_64-pc-linux-gnu >> ... >> > > I checked it again. I also passed i686-linux, not --host=, to configure. Ok I see, the configure line you pasted was wrapped by your email client so was not very readable. Doing `./configure ` looks like a deprecated way to set all build/host/target, as the warning message it shows implies: configure: WARNING: you should use --build, --host, --target Anyway, my point still stands: the problem is you not using a pkg-config configured properly for the cross compilation you are attempting, not pkg.m4. >> >> And even if it worked, why would it set "build" to i686, it doesn't make >> sense. The gcc you >> compile with, and its environment, is still x86_64, not i686. >> >> So *if* it works, it would be a shortcut for setting --host=i686-something, >> maybe. So >> regardless of how that above works, that doesn't remove the need to >> configure pkg-config >> correctly for the host system. >> >> If you don't want to learn about with pkg-config and deal with it, then >> please say "I think >> we should not use pkg-config", and ideally give supporting points. Please >> don't unilaterally >> push patches just to paper over your own problems. You just make it so that >> somebody will >> need to untangle more mess later. > > I am OK to remove pkg.m4. Well I am not. I find it quite handy to avoid having to hardcode necessary CFLAGS and LDFLAGS required to build against a library, so I think it's better to use pkg-config if the libraries we want to use provide a .pc file. I propose that we revert the patch for now to go back to the pristing pkg.m4 version. Simon
Re: V2 [PATCH] PKG_CHECK_MODULES: Check if $pkg_cv_[]$1[]_LIBS works
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 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 together.
>>>>
>>>>> I didn't set PKG_CONFIG_LIBDIR and I don't want to set it.
>>>>
>>>> Then use the correct pkg-config for your target. If you think
>>>> pkg-config is broken, then fix _that_.
>>>>
>>>
>>> I did:
>>>
>>> RUNTESTFLAGS="--target_board 'unix{-m32}'" CC="gcc -m32 -fno-lto
>>> -fcf-protection"
>>> CXX="g++ -fno-lto -m32 -fcf-protection" /exp
>>> ort/gnu/import/git/gitlab/x86-binutils/configure \
>>> --enable-targets=x86_64-linux \
>>> i686-linux \
>>> --enable-plugins --disable-gdb --disable-gdbserver --disable-libdecnumbe
>>> r --disable-readline --disable-sim --with-sysroot=/ --with-system-zlib \
>>> --prefix=/usr/local \
>>> --with-local-prefix=/usr/local
>>> configure: WARNING: you should use --build, --host, --target
>>> checking build system type... i686-pc-linux-gnu
>>> checking host system type... i686-pc-linux-gnu
>>> checking target system type... i686-pc-linux-gnu
>>
>> So... is your build system a 32-bit one? Why does the above say
>> i686-pc-linux-gnu
>> and not x86_64-something?
>>
>
> My system supports both -m32 and -m64. Depending on CC, configure
> selects i686 or x86-64 target.
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 -m32" CXX="g++ -m32"
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking target system type... x86_64-pc-linux-gnu
...
And even if it worked, why would it set "build" to i686, it doesn't make sense.
The gcc you
compile with, and its environment, is still x86_64, not i686.
So *if* it works, it would be a shortcut for setting --host=i686-something,
maybe. So
regardless of how that above works, that doesn't remove the need to configure
pkg-config
correctly for the host system.
If you don't want to learn about with pkg-config and deal with it, then please
say "I think
we should not use pkg-config", and ideally give supporting points. Please
don't unilaterally
push patches just to paper over your own problems. You just make it so that
somebody will
need to untangle more mess later.
Simon
Re: V2 [PATCH] PKG_CHECK_MODULES: Check if $pkg_cv_[]$1[]_LIBS works
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 together.
>>
>>> I didn't set PKG_CONFIG_LIBDIR and I don't want to set it.
>>
>> Then use the correct pkg-config for your target. If you think
>> pkg-config is broken, then fix _that_.
>>
>
> I did:
>
> RUNTESTFLAGS="--target_board 'unix{-m32}'" CC="gcc -m32 -fno-lto
> -fcf-protection"
> CXX="g++ -fno-lto -m32 -fcf-protection" /exp
> ort/gnu/import/git/gitlab/x86-binutils/configure \
> --enable-targets=x86_64-linux \
> i686-linux \
> --enable-plugins --disable-gdb --disable-gdbserver --disable-libdecnumbe
> r --disable-readline --disable-sim --with-sysroot=/ --with-system-zlib \
> --prefix=/usr/local \
> --with-local-prefix=/usr/local
> configure: WARNING: you should use --build, --host, --target
> checking build system type... i686-pc-linux-gnu
> checking host system type... i686-pc-linux-gnu
> checking target system type... i686-pc-linux-gnu
So... is your build system a 32-bit one? Why does the above say
i686-pc-linux-gnu
and not x86_64-something?
Simon
Re: V2 [PATCH] PKG_CHECK_MODULES: Check if $pkg_cv_[]$1[]_LIBS works
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 blame >> you, it's not made in an intuitive way). The problem is that you were using >> pkg-config as >> configured to look up x86_64 packages. It looks up .pc files in (amongst >> others) >> /usr/lib64/pkgconfig, which provides information about x86_64 packages, >> which are in turn obviously >> not suitable not suitable to build a i686 program. Just like you >> cross-compile "for real" (say, >> for an ARM host), you need to set PKG_CONFIG or the PKG_CONFIG_* variables >> to returns packages for >> the --host architecture. That means searching in /usr/lib/pkgconfig instead >> of /usr/lib64/pkgconfig. >> >> You could for example set the PKG_CONFIG_LIBDIR variable to >> /usr/lib/pkgconfig:/usr/share/pkgconfig > > I didn't set PKG_CONFIG_LIBDIR and I don't want to set it. Why are you fine adjusting CC="gcc -m32" but not PKG_CONFIG*? > >> This way, if you don't install the elfutils-debuginfod-client-devel.i686 >> package, your binutils won't >> try to link with libdebuginfod (because pkg-config won't find it). If you >> install it, then your >> binutils will be built against the i686 libdebuginfod. >> >> Ideally, distros would ship a i686-something-something-pkg-config that >> automatically searchs in paths >> that make sense for that architecture (just like you have >> arm-linux-gnueabihf-pkg-config when cross >> compiling for ARM), but that doesn't seem to exist. But this is just like >> you have to explicitly set >> CC="gcc -m32" instead of using some i686-something-something-gcc. >> >> You can always make it yourself, create, say, a >> `i686-pc-linux-gnu-pkg-config` file somewhere in $PATH, >> with: >> >> export PKG_CONFIG_LIBDIR=/usr/lib/pkgconfig:/usr/share/pkgconfig >> exec pkg-config $* > > I don't want to do it. PKG_CHECK_MODULES should check if the library > really works. > Otherwise we can use remove it and use the library directly without checking. We could, but that would have its own disadvantages. Simon
Re: V2 [PATCH] PKG_CHECK_MODULES: Check if $pkg_cv_[]$1[]_LIBS works
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 at 9:01 AM H.J. Lu wrote: >> This caused: >> >> https://sourceware.org/bugzilla/show_bug.cgi?id=26301 >> > > It is quite normal to have debuginfod headers without libdebuginfod on > multilib OSes. Restore AC_CHECK_LIB to check if libdebuginfod exists. > And always define HAVE_LIBDEBUGINFOD to 0 or 1 for > > binutils/dwarf.c:#if HAVE_LIBDEBUGINFOD > binutils/dwarf.c:#if HAVE_LIBDEBUGINFOD > binutils/dwarf.c:#if HAVE_LIBDEBUGINFOD > binutils/dwarf.h:#if HAVE_LIBDEBUGINFOD > binutils/objdump.c:#if HAVE_LIBDEBUGINFOD > binutils/objdump.c:#endif /* HAVE_LIBDEBUGINFOD */ > binutils/readelf.c:#if HAVE_LIBDEBUGINFOD > binutils/readelf.c:#endif /* HAVE_LIBDEBUGINFOD */ > gdb/top.c:#if HAVE_LIBDEBUGINFOD > > OK for master? Thanks for spotting this. Normally PKG_CHECH_MODULES would correctly detect whether the .so and header are installed and build accordingly, but when cross compiling the AC_CHECK_LIB may be needed. >>> >>> I am not cross compiling. I am simply using "gcc -m32". The problem >>> is PKG_CHECK_MODULES which doesn't check if $pkg_cv_[]$1[]_LIBS >>> actually works. Here is the updated patch to fix PKG_CHECK_MODULES. >>> Any comments or objections? >>> >>> >> >> HAVE_LIBDEBUGINFOD is a separate issue. Here is the updated patch >> which only adds AC_TRY_LINK to PKG_CHECK_MODULES to check if >> $pkg_cv_[]$1[]_LIBS works. >> > > I am checking it in. > > -- > H.J. > You said that you are not cross-compiling, but technically I'd say you are cross compiling, since you are building for a different architecture than what the compiler is running. You are probably configuring with --host=i686-something-something? Anyway regardless of vocabulary, I don't think there was a problem to begin with (not that I blame you, it's not made in an intuitive way). The problem is that you were using pkg-config as configured to look up x86_64 packages. It looks up .pc files in (amongst others) /usr/lib64/pkgconfig, which provides information about x86_64 packages, which are in turn obviously not suitable not suitable to build a i686 program. Just like you cross-compile "for real" (say, for an ARM host), you need to set PKG_CONFIG or the PKG_CONFIG_* variables to returns packages for the --host architecture. That means searching in /usr/lib/pkgconfig instead of /usr/lib64/pkgconfig. You could for example set the PKG_CONFIG_LIBDIR variable to /usr/lib/pkgconfig:/usr/share/pkgconfig This way, if you don't install the elfutils-debuginfod-client-devel.i686 package, your binutils won't try to link with libdebuginfod (because pkg-config won't find it). If you install it, then your binutils will be built against the i686 libdebuginfod. Ideally, distros would ship a i686-something-something-pkg-config that automatically searchs in paths that make sense for that architecture (just like you have arm-linux-gnueabihf-pkg-config when cross compiling for ARM), but that doesn't seem to exist. But this is just like you have to explicitly set CC="gcc -m32" instead of using some i686-something-something-gcc. You can always make it yourself, create, say, a `i686-pc-linux-gnu-pkg-config` file somewhere in $PATH, with: export PKG_CONFIG_LIBDIR=/usr/lib/pkgconfig:/usr/share/pkgconfig exec pkg-config $* Then, when you configure with --host=i686-pc-linux-gnu, AC_PATH_TOOL will automatically pick up that as the pkg-config to use, and everything will work seamlessly. So, I concede that it's not intuitive, but I think your patch is not right because it just hides the mis-configuration. If `pkg-config` says a lib exists but we are not able to link with it, there is a bigger problem than "lib not found". I think it should be a hard error (abort configure) and tell the user about it: "pkg-config says that libfoo is available but we can't link with it, are you maybe using the wrong pkg-config, or a wrong pkg-config path?". Finally, the file you modified is maintained upstream here: https://cgit.freedesktop.org/pkg-config/tree/pkg.m4.in Do you intend to submit your changes there? Otherwise, they will be overwritten next time we sync with upstream. Simon
Re: [PATCH] config/debuginfod.m4: Use PKG_CHECK_MODULES
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 pkg.m4 into aclocal.m4, how about making
>> config/pkg.m4 and then using m4_include from gdb/acinclude.m4?
>> That's what gdb does for other shared m4 code.
>
> Resending the patch for this since my last attempt didn't seem to
> properly reply to
> Tom's email.
>
Since it's debuginfo.m4 that is using PKG_CHECK_MODULES, can you put the include
of pkg.m4 in debuginfo.m4, instead of in {binutils,gdb}/configure.ac?
Otherwise, from GDB's point of view I think it looks good, unless Tom has some
things to add.
Simon
Re: [PATCH wwwdocs] Mention GNU Tools Cauldron in the News section
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
Re: [PATCH wwwdocs] Mention GNU Tools Cauldron in the News section
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 > === > RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v > retrieving revision 1.1125 > diff -u -r1.1125 index.html > --- index.html29 Mar 2019 12:28:15 - 1.1125 > +++ index.html15 Apr 2019 16:39:00 - > @@ -54,6 +54,10 @@ > News > > > +https://gcc.gnu.org/wiki/cauldron2019;>GNU Tools Cauldron > 2019 > +[2019-04-15] > +Held in Montréal, Canada, September 13-15 2019 > + > GCC 8.3 released > [2019-02-22] > > Actually, it would be better to use the same dates as are written on the wiki (12-15), so please consider the patch below instead. Also, please note that I don't have push access on GCC, so if somebody could push the patch for me, once it's approved, I would appreciate it. Thanks! Index: index.html === RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v retrieving revision 1.1125 diff -u -r1.1125 index.html --- index.html 29 Mar 2019 12:28:15 - 1.1125 +++ index.html 15 Apr 2019 17:34:48 - @@ -54,6 +54,10 @@ News +https://gcc.gnu.org/wiki/cauldron2019;>GNU Tools Cauldron 2019 +[2019-04-15] +Held in Montréal, Canada, September 12-15 2019 + GCC 8.3 released [2019-02-22]
[PATCH wwwdocs] Mention GNU Tools Cauldron in the News section
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 -r1.1125 index.html --- index.html 29 Mar 2019 12:28:15 - 1.1125 +++ index.html 15 Apr 2019 16:39:00 - @@ -54,6 +54,10 @@ News +https://gcc.gnu.org/wiki/cauldron2019;>GNU Tools Cauldron 2019 +[2019-04-15] +Held in Montréal, Canada, September 13-15 2019 + GCC 8.3 released [2019-02-22]
[PATCH (sync with binutils-gdb)] Don't build readline/libreadline.a, when --with-system-readline is supplied
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 the build libreadline.a is not used. Proposed patch: Fix ./configure.ac not to proceed readline/, when --with-system- readline is provided --- ChangeLog| 7 +++ configure| 6 ++ configure.ac | 6 ++ 3 files changed, 19 insertions(+) diff --git a/ChangeLog b/ChangeLog index a86c3fc40c01..5c98e93d1922 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,10 @@ +2019-01-03 Дилян Палаузов + + Merge from binutils-gdb: + * configure.ac: Don't configure readline if --with-system-readline is + used. + * configure: Re-generate. + 2018-12-21 Thomas Preud'homme * MAINTAINERS (Write After Approval): Update my maintainer address. diff --git a/configure b/configure index 4b095de5b0ae..29c2eebc81b9 100755 --- a/configure +++ b/configure @@ -2920,6 +2920,12 @@ if test x$with_system_zlib = xyes ; then noconfigdirs="$noconfigdirs zlib" fi +# Don't compile the bundled readline/libreadline.a if --with-system-readline +# is provided. +if test x$with_system_readline = xyes ; then + noconfigdirs="$noconfigdirs readline" +fi + # some tools are so dependent upon X11 that if we're not building with X, # it's not even worth trying to configure, much less build, that tool. diff --git a/configure.ac b/configure.ac index 05475105ffc0..2c4b917e5334 100644 --- a/configure.ac +++ b/configure.ac @@ -246,6 +246,12 @@ if test x$with_system_zlib = xyes ; then noconfigdirs="$noconfigdirs zlib" fi +# Don't compile the bundled readline/libreadline.a if --with-system-readline +# is provided. +if test x$with_system_readline = xyes ; then + noconfigdirs="$noconfigdirs readline" +fi + # some tools are so dependent upon X11 that if we're not building with X, # it's not even worth trying to configure, much less build, that tool. -- 2.20.1
Re: RFC: libiberty PATCH to disable demangling of ancient mangling schemes
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 to start with? Hi Jason >From the GDB point of view, I don't see any problem. Please proceed with the cleanup, it should be quite easy to adjust our code when we sync libiberty. There is a usage of cplus_mangle_opname in binutils/stabs.c, and I can't speak for binutils. But speaking of cplus_mangle_opname, shouldn't you also remove the declaration in include/demangle.h? Simon
Re: Small typo in iconv.m4
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 following line. CPPFLAGS="$LIBS $INCICONV" which should have been CPPFLAGS="$CPPFLAGS $INCICONV" OK to commit the attached patch? 2018-11-06 Hafiz Abid Qadeer * config/iconv.m4 (AM_ICONV_LINK): Don't overwrite CPPFLAGS. Append $INCICONV to it. * gcc/configure: Regenerate. * libcpp/configure: Likewise. * libstdc++-v3/configure: Likewise. * intl/configure: Likewise. Thanks, Seems good from my point of view, but I can't approve. Simon
Re: Update GCC to autoconf 2.69, automake 1.15.1
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 seems a useful incremental update that > should make a future update to 1.16.1 easier.) Whenever you feel like bumping gcc to 1.16.1, I can take care of binutils-gdb. Simon
Re: [PATCH] Backport gettext fixes to get rid of warnings on macOS
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). Although I
> think
> it is relatively low-risk, building gcc on macOS was not tested with this
> patch, so if somebody that has already a macOS build can do it, it would be
> appreciated.
>
> Two fixes were committed recently to the gettext repo in order to make
> gdb build warning-free on macOS. This patch backports them both:
>
> - Make the format_arg attribute effective also in the case
> _INTL_REDIRECT_INLINE.
> 113893dce80358a4ae0d9463ce73c5670c81cf0c
>
> http://git.savannah.gnu.org/cgit/gettext.git/commit/?id=113893dce80358a4ae0d9463ce73c5670c81cf0c
>
> - Enable the format_arg attribute also on clang on Mac OS X.
> bd6a52241c7c83c90e043ace2082a2508d273f55
>
> http://git.savannah.gnu.org/cgit/gettext.git/commit/?id=bd6a52241c7c83c90e043ace2082a2508d273f55
>
> intl/ChangeLog:
>
> * libgnuintl.h (_INTL_MAY_RETURN_STRING_ARG, gettext, dgettext,
> dcgettext, ngettext, dngettext, dcngettext): Backport changes
> from upstream gettext.
> ---
> intl/libgnuintl.h | 35 +++
> 1 file changed, 23 insertions(+), 12 deletions(-)
>
> diff --git a/intl/libgnuintl.h b/intl/libgnuintl.h
> index acc9093..7616d6f 100644
> --- a/intl/libgnuintl.h
> +++ b/intl/libgnuintl.h
> @@ -115,7 +115,7 @@ extern "C" {
> /* _INTL_MAY_RETURN_STRING_ARG(n) declares that the given function may return
> its n-th argument literally. This enables GCC to warn for example about
> printf (gettext ("foo %y")). */
> -#if __GNUC__ >= 3 && !(__APPLE_CC__ > 1 && defined __cplusplus)
> +#if defined __GNUC__ && __GNUC__ >= 3 && !(defined __APPLE_CC__ &&
> __APPLE_CC__ > 1 && !(defined __clang__ && __clang__ && __clang_major__ >= 3)
> && defined __cplusplus)
> # define _INTL_MAY_RETURN_STRING_ARG(n) __attribute__ ((__format_arg__ (n)))
> #else
> # define _INTL_MAY_RETURN_STRING_ARG(n)
> @@ -127,7 +127,9 @@ extern "C" {
> #ifdef _INTL_REDIRECT_INLINE
> extern char *libintl_gettext (const char *__msgid)
> _INTL_MAY_RETURN_STRING_ARG (1);
> -static inline char *gettext (const char *__msgid)
> +static inline
> +_INTL_MAY_RETURN_STRING_ARG (1)
> +char *gettext (const char *__msgid)
> {
>return libintl_gettext (__msgid);
> }
> @@ -145,7 +147,9 @@ extern char *gettext _INTL_PARAMS ((const char *__msgid))
> #ifdef _INTL_REDIRECT_INLINE
> extern char *libintl_dgettext (const char *__domainname, const char *__msgid)
> _INTL_MAY_RETURN_STRING_ARG (2);
> -static inline char *dgettext (const char *__domainname, const char *__msgid)
> +static inline
> +_INTL_MAY_RETURN_STRING_ARG (2)
> +char *dgettext (const char *__domainname, const char *__msgid)
> {
>return libintl_dgettext (__domainname, __msgid);
> }
> @@ -165,8 +169,9 @@ extern char *dgettext _INTL_PARAMS ((const char
> *__domainname,
> extern char *libintl_dcgettext (const char *__domainname, const char
> *__msgid,
> int __category)
> _INTL_MAY_RETURN_STRING_ARG (2);
> -static inline char *dcgettext (const char *__domainname, const char *__msgid,
> -int __category)
> +static inline
> +_INTL_MAY_RETURN_STRING_ARG (2)
> +char *dcgettext (const char *__domainname, const char *__msgid, int
> __category)
> {
>return libintl_dcgettext (__domainname, __msgid, __category);
> }
> @@ -188,8 +193,10 @@ extern char *dcgettext _INTL_PARAMS ((const char
> *__domainname,
> extern char *libintl_ngettext (const char *__msgid1, const char *__msgid2,
> unsigned long int __n)
> _INTL_MAY_RETURN_STRING_ARG (1) _INTL_MAY_RETURN_STRING_ARG (2);
> -static inline char *ngettext (const char *__msgid1, const char *__msgid2,
> - unsigned long int __n)
> +static inline
> +_INTL_MAY_RETURN_STRING_ARG (1) _INTL_MAY_RETURN_STRING_ARG (2)
> +char *ngettext (const char *__msgid1, const char *__msgid2,
> + unsigned long int __n)
> {
>return libintl_ngettext (__msgid1, __msgid2, __n);
> }
> @@ -210,8 +217,10 @@ extern char *ngettext _INTL_PARAMS ((const char
> *__msgid1,
> extern char *libintl_dngettext (const char *__domainname, const char
> *__msgid1,
> const char *__msgid2, unsigned long int __n)
> _INTL_MAY_RETURN_STRING_ARG
Re: [PATCH 2/3] GDB: Add support for 24 bit addresses
(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 DW_EH_PE_udata3
---
gdb/dwarf2-frame.c | 7 ++-
include/dwarf2.h | 5 -
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/gdb/dwarf2-frame.c b/gdb/dwarf2-frame.c
index f7dc820f4d..b329e34997 100644
--- a/gdb/dwarf2-frame.c
+++ b/gdb/dwarf2-frame.c
@@ -1527,12 +1527,14 @@ encoding_for_size (unsigned int size)
{
case 2:
return DW_EH_PE_udata2;
+case 3:
+ return DW_EH_PE_udata3;
case 4:
return DW_EH_PE_udata4;
case 8:
return DW_EH_PE_udata8;
default:
- internal_error (__FILE__, __LINE__, _("Unsupported address
size"));
+ internal_error (__FILE__, __LINE__, _("Unsupported address size
%d"), size);
}
}
@@ -1605,6 +1607,9 @@ read_encoded_value (struct comp_unit *unit,
gdb_byte encoding,
case DW_EH_PE_udata2:
*bytes_read_ptr += 2;
return (base + bfd_get_16 (unit->abfd, (bfd_byte *) buf));
+case DW_EH_PE_udata3:
+ *bytes_read_ptr += 3;
+ return (base + bfd_get_24 (unit->abfd, (bfd_byte *) buf));
case DW_EH_PE_udata4:
*bytes_read_ptr += 4;
return (base + bfd_get_32 (unit->abfd, (bfd_byte *) buf));
diff --git a/include/dwarf2.h b/include/dwarf2.h
index cf0039a92a..05c328057b 100644
--- a/include/dwarf2.h
+++ b/include/dwarf2.h
@@ -474,11 +474,14 @@ enum dwarf_unit_type
#define DW_EH_PE_udata20x02
#define DW_EH_PE_udata40x03
#define DW_EH_PE_udata80x04
+
+#define DW_EH_PE_udata30x05
+
+#define DW_EH_PE_signed0x08
#define DW_EH_PE_sleb128 0x09
#define DW_EH_PE_sdata20x0A
#define DW_EH_PE_sdata40x0B
#define DW_EH_PE_sdata80x0C
-#define DW_EH_PE_signed0x08
#define DW_EH_PE_pcrel 0x10
#define DW_EH_PE_textrel 0x20
This file is owned by GCC (see the MAINTAINERS file at the top of
binutils-gdb). To get a modification in it, you would need to provide a
patch to gcc, then we can import the change in binutils-gdb.
I am not too sure who is responsible for allocating these values, as
they are not from the DWARF standard. At the very least, there should
be a comment to say what architecture uses this non-standard value. Is
there also a gcc port you are planning to upstream, that would use this
value?
Simon
Re: [PATCH] Backport gettext fixes to get rid of warnings on macOS
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 upstream gettext. Thanks, I think you should check this in. I was hoping to get an approval from gcc and binutils first, but this is probably obvious enough, so I pushed it in. Could somebody from gcc take care of merging it in gcc too? Thanks, Simon
Re: [PATCH] Backport gettext fixes to get rid of warnings on macOS
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 it is relatively low-risk, building gcc on macOS was not tested with this patch, so if somebody that has already a macOS build can do it, it would be appreciated. Actually it can be applied cleanly in gcc too, I just forgot I had some local commits touching the same spots. Simon
[PATCH] Backport gettext fixes to get rid of warnings on macOS
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 tested with this
patch, so if somebody that has already a macOS build can do it, it would be
appreciated.
Two fixes were committed recently to the gettext repo in order to make
gdb build warning-free on macOS. This patch backports them both:
- Make the format_arg attribute effective also in the case
_INTL_REDIRECT_INLINE.
113893dce80358a4ae0d9463ce73c5670c81cf0c
http://git.savannah.gnu.org/cgit/gettext.git/commit/?id=113893dce80358a4ae0d9463ce73c5670c81cf0c
- Enable the format_arg attribute also on clang on Mac OS X.
bd6a52241c7c83c90e043ace2082a2508d273f55
http://git.savannah.gnu.org/cgit/gettext.git/commit/?id=bd6a52241c7c83c90e043ace2082a2508d273f55
intl/ChangeLog:
* libgnuintl.h (_INTL_MAY_RETURN_STRING_ARG, gettext, dgettext,
dcgettext, ngettext, dngettext, dcngettext): Backport changes
from upstream gettext.
---
intl/libgnuintl.h | 35 +++
1 file changed, 23 insertions(+), 12 deletions(-)
diff --git a/intl/libgnuintl.h b/intl/libgnuintl.h
index acc9093..7616d6f 100644
--- a/intl/libgnuintl.h
+++ b/intl/libgnuintl.h
@@ -115,7 +115,7 @@ extern "C" {
/* _INTL_MAY_RETURN_STRING_ARG(n) declares that the given function may return
its n-th argument literally. This enables GCC to warn for example about
printf (gettext ("foo %y")). */
-#if __GNUC__ >= 3 && !(__APPLE_CC__ > 1 && defined __cplusplus)
+#if defined __GNUC__ && __GNUC__ >= 3 && !(defined __APPLE_CC__ &&
__APPLE_CC__ > 1 && !(defined __clang__ && __clang__ && __clang_major__ >= 3)
&& defined __cplusplus)
# define _INTL_MAY_RETURN_STRING_ARG(n) __attribute__ ((__format_arg__ (n)))
#else
# define _INTL_MAY_RETURN_STRING_ARG(n)
@@ -127,7 +127,9 @@ extern "C" {
#ifdef _INTL_REDIRECT_INLINE
extern char *libintl_gettext (const char *__msgid)
_INTL_MAY_RETURN_STRING_ARG (1);
-static inline char *gettext (const char *__msgid)
+static inline
+_INTL_MAY_RETURN_STRING_ARG (1)
+char *gettext (const char *__msgid)
{
return libintl_gettext (__msgid);
}
@@ -145,7 +147,9 @@ extern char *gettext _INTL_PARAMS ((const char *__msgid))
#ifdef _INTL_REDIRECT_INLINE
extern char *libintl_dgettext (const char *__domainname, const char *__msgid)
_INTL_MAY_RETURN_STRING_ARG (2);
-static inline char *dgettext (const char *__domainname, const char *__msgid)
+static inline
+_INTL_MAY_RETURN_STRING_ARG (2)
+char *dgettext (const char *__domainname, const char *__msgid)
{
return libintl_dgettext (__domainname, __msgid);
}
@@ -165,8 +169,9 @@ extern char *dgettext _INTL_PARAMS ((const char
*__domainname,
extern char *libintl_dcgettext (const char *__domainname, const char *__msgid,
int __category)
_INTL_MAY_RETURN_STRING_ARG (2);
-static inline char *dcgettext (const char *__domainname, const char *__msgid,
- int __category)
+static inline
+_INTL_MAY_RETURN_STRING_ARG (2)
+char *dcgettext (const char *__domainname, const char *__msgid, int __category)
{
return libintl_dcgettext (__domainname, __msgid, __category);
}
@@ -188,8 +193,10 @@ extern char *dcgettext _INTL_PARAMS ((const char
*__domainname,
extern char *libintl_ngettext (const char *__msgid1, const char *__msgid2,
unsigned long int __n)
_INTL_MAY_RETURN_STRING_ARG (1) _INTL_MAY_RETURN_STRING_ARG (2);
-static inline char *ngettext (const char *__msgid1, const char *__msgid2,
- unsigned long int __n)
+static inline
+_INTL_MAY_RETURN_STRING_ARG (1) _INTL_MAY_RETURN_STRING_ARG (2)
+char *ngettext (const char *__msgid1, const char *__msgid2,
+ unsigned long int __n)
{
return libintl_ngettext (__msgid1, __msgid2, __n);
}
@@ -210,8 +217,10 @@ extern char *ngettext _INTL_PARAMS ((const char *__msgid1,
extern char *libintl_dngettext (const char *__domainname, const char *__msgid1,
const char *__msgid2, unsigned long int __n)
_INTL_MAY_RETURN_STRING_ARG (2) _INTL_MAY_RETURN_STRING_ARG (3);
-static inline char *dngettext (const char *__domainname, const char *__msgid1,
- const char *__msgid2, unsigned long int __n)
+static inline
+_INTL_MAY_RETURN_STRING_ARG (2) _INTL_MAY_RETURN_STRING_ARG (3)
+char *dngettext (const char *__domainname, const char *__msgid1,
+const char *__msgid2, unsigned long int __n)
{
return libintl_dngettext (__domainname, __msgid1, __msgid2, __n);
}
@@ -234,9 +243,11 @@ extern char *libintl_dcngettext (const char *__domainname,
const char *__msgid1, const char *__msgid2,
