Re: [bug #65537] Werrors from intprops-internal.h with gcc 8.3.0

[Jeffrey Walton]

On Fri, Mar 29, 2024 at 2:15 PM Martin Dorey  wrote:
>
> URL:
>   
>
>  Summary: Werrors from intprops-internal.h with gcc 8.3.0
>Group: make
>Submitter: mdorey
>Submitted: Fri 29 Mar 2024 11:14:56 AM PDT
> Severity: 3 - Normal
>   Item Group: Build/Install
>   Status: None
>  Privacy: Public
>  Assigned to: None
>  Open/Closed: Open
>  Discussion Lock: Any
>Component Version: SCM
> Operating System: POSIX-Based
>Fixed Release: None
>Triage Status: None
>
>
> ___
>
> Follow-up Comments:
>
>
> ---
> Date: Fri 29 Mar 2024 11:14:56 AM PDT By: Martin Dorey 
> A fresh git clone of Gnu Make fails to build for me on Debian 10/Buster with:
>
> mv -f $depbase.Tpo $depbase.Po
> In file included from lib/intprops.h:21,
>  from src/arscan.c:379:
> src/arscan.c: In function ‘parse_int’:
> lib/intprops-internal.h:39:59: error: comparison of unsigned expression < 0 is
> always false [-Werror=type-limits]
>  #define _GL_EXPR_SIGNED(e) (_GL_INT_NEGATE_CONVERT (e, 1) < 0)
>^
> lib/intprops-internal.h:166:42: note: in expansion of macro
> ‘_GL_EXPR_SIGNED’
>  ((!_GL_SIGNED_TYPE_OR_EXPR (*(r)) && _GL_EXPR_SIGNED (a) &&
> _GL_EXPR_SIGNED (b) \
>   ^~~
> lib/intprops.h:302:37: note: in expansion of macro
> ‘_GL_INT_MULTIPLY_WRAPV’
>  #define INT_MULTIPLY_WRAPV(a, b, r) _GL_INT_MULTIPLY_WRAPV (a, b, r)
>  ^~
> src/arscan.c:399:14: note: in expansion of macro ‘INT_MULTIPLY_WRAPV’
>|| INT_MULTIPLY_WRAPV (val, base, )
>   ^~
> lib/intprops-internal.h:372:11: error: comparison of unsigned expression < 0
> is always false [-Werror=type-limits]
> ? ((a) < 0 \
>^
> lib/intprops-internal.h:167:10: note: in expansion of macro
> ‘_GL_INT_MULTIPLY_RANGE_OVERFLOW’
>&& _GL_INT_MULTIPLY_RANGE_OVERFLOW (a, b, 0, (__typeof__ (*(r))) -1))
> \
>   ^~~
> lib/intprops.h:302:37: note: in expansion of macro
> ‘_GL_INT_MULTIPLY_WRAPV’
>  #define INT_MULTIPLY_WRAPV(a, b, r) _GL_INT_MULTIPLY_WRAPV (a, b, r)
>  ^~
> src/arscan.c:399:14: note: in expansion of macro ‘INT_MULTIPLY_WRAPV’
>|| INT_MULTIPLY_WRAPV (val, base, )
>   ^~
> lib/intprops-internal.h:39:59: error: comparison of unsigned expression < 0 is
> always false [-Werror=type-limits]
>  #define _GL_EXPR_SIGNED(e) (_GL_INT_NEGATE_CONVERT (e, 1) < 0)
>^
> lib/intprops-internal.h:373:10: note: in expansion of macro
> ‘_GL_EXPR_SIGNED’
>? (_GL_EXPR_SIGNED (_GL_INT_CONVERT (tmax, b)) \
>   ^~~
> lib/intprops-internal.h:167:10: note: in expansion of macro
> ‘_GL_INT_MULTIPLY_RANGE_OVERFLOW’
>&& _GL_INT_MULTIPLY_RANGE_OVERFLOW (a, b, 0, (__typeof__ (*(r))) -1))
> \
>   ^~~
> lib/intprops.h:302:37: note: in expansion of macro
> ‘_GL_INT_MULTIPLY_WRAPV’
>  #define INT_MULTIPLY_WRAPV(a, b, r) _GL_INT_MULTIPLY_WRAPV (a, b, r)
>  ^~
> src/arscan.c:399:14: note: in expansion of macro ‘INT_MULTIPLY_WRAPV’
>|| INT_MULTIPLY_WRAPV (val, base, )
>   ^~
> lib/intprops-internal.h:39:59: error: comparison of unsigned expression < 0 is
> always false [-Werror=type-limits]
>  #define _GL_EXPR_SIGNED(e) (_GL_INT_NEGATE_CONVERT (e, 1) < 0)
>^
> lib/intprops-internal.h:380:10: note: in expansion of macro
> ‘_GL_EXPR_SIGNED’
>? (_GL_EXPR_SIGNED (a) \
>   ^~~
> lib/intprops-internal.h:167:10: note: in expansion of macro
> ‘_GL_INT_MULTIPLY_RANGE_OVERFLOW’
>&& _GL_INT_MULTIPLY_RANGE_OVERFLOW (a, b, 0, (__typeof__ (*(r))) -1))
> \
>   ^~~
> lib/intprops.h:302:37: note: in expansion of macro
> ‘_GL_INT_MULTIPLY_WRAPV’
>  #define INT_MULTIPLY_WRAPV(a, b, r) _GL_INT_MULTIPLY_WRAPV (a, b, r)
>  ^~
> src/arscan.c:399:14: note: in expansion of macro ‘INT_MULTIPLY_WRAPV’
>|| INT_MULTIPLY_WRAPV (val, base, )
>   ^~
> lib/intprops-internal.h:382:35: error: comparison of integer expressions of
> different signedness: ‘int’ and ‘uintmax_t’ {aka ‘long unsigned
> int’} [-Werror=sign-compare]
>   : 0 < (a) && -1 - (tmin) < (a) - 1) \
>

Re: MAKEFLAGS=-r

[Jeffrey Walton]

On Mon, Jul 17, 2023 at 11:47 AM Paul Smith  wrote:
>
> On Mon, 2023-07-17 at 11:45 +0200, Bruno Haible wrote:
> > Dmitry Goncharov wrote:
> > > Once the makefile author knows the makefile does not need built-in
> > > rules, they should add MAKEFLAGS=-r in the makefile and
> > > this will do a good service to all their users.
>
> I'm not sure I've followed the entire discussion yet, but FYI I do not
> usually recommend this method of clearing the default rules.  There are
> issues with modifying MAKEFLAGS, especially with some older versions of
> GNU Make.  And also, in some older versions setting MAKEFLAGS in the
> makefile doesn't actually take effect anyway: it only helps for sub-
> makes.
>
> My recommendation has been to disable the built-in rules directly, if
> you don't need them.  For example you can use:
>
>   .SUFFIXES:
>
> to disable most of the built in rules (this is a POSIX standard
> facility so it's helpful even for other versions of make).
>
> Unfortunately that doesn't fix all problems because GNU Make also has a
> few built-in rules that are defined using pattern rules (because suffix
> rules are not powerful enough).  So a full list of "turn it all off"
> would be this:
>
>   .SUFFIXES:
>   %:: %,v
>   %:: RCS/%,v
>   %:: RCS/%
>   %:: s.%
>   %:: SCCS/s.%

SUFFIXES does not seem to work too well. 'make -d' still shows all the
extra noise. For example, I added to the top of my GNUmakefile:

   .SUFFIXES: .h .c .cpp .S .o

I still see:

$ make -d -f GNUmakefile
GNU Make 4.3
Built for x86_64-pc-linux-gnu
Copyright (C) 1988-2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Reading makefiles...
Reading makefile 'GNUmakefile'...
Updating makefiles
 Considering target file 'GNUmakefile'.
  Looking for an implicit rule for 'GNUmakefile'.
  Trying pattern rule with stem 'GNUmakefile'.
  Trying implicit prerequisite 'GNUmakefile.o'.
  Trying pattern rule with stem 'GNUmakefile'.
  Trying implicit prerequisite 'GNUmakefile.c'.
  Trying pattern rule with stem 'GNUmakefile'.
  Trying implicit prerequisite 'GNUmakefile.cc'.
  Trying pattern rule with stem 'GNUmakefile'.
  Trying implicit prerequisite 'GNUmakefile.C'.
  Trying pattern rule with stem 'GNUmakefile'.
  Trying implicit prerequisite 'GNUmakefile.cpp'.
  Trying pattern rule with stem 'GNUmakefile'.
  Trying implicit prerequisite 'GNUmakefile.p'.
  Trying pattern rule with stem 'GNUmakefile'.
  Trying implicit prerequisite 'GNUmakefile.f'.
  Trying pattern rule with stem 'GNUmakefile'.
  Trying implicit prerequisite 'GNUmakefile.F'.
  Trying pattern rule with stem 'GNUmakefile'.
  Trying implicit prerequisite 'GNUmakefile.m'.
  Trying pattern rule with stem 'GNUmakefile'.
  Trying implicit prerequisite 'GNUmakefile.r'.
  Trying pattern rule with stem 'GNUmakefile'.
  Trying implicit prerequisite 'GNUmakefile.s'.
  Trying pattern rule with stem 'GNUmakefile'.
  Trying implicit prerequisite 'GNUmakefile.S'.
  Trying pattern rule with stem 'GNUmakefile'.
  Trying implicit prerequisite 'GNUmakefile.mod'.
  Trying pattern rule with stem 'GNUmakefile'.
  Trying implicit prerequisite 'GNUmakefile.sh'.
  Trying pattern rule with stem 'GNUmakefile'.
  Trying implicit prerequisite 'GNUmakefile,v'.
  Trying pattern rule with stem 'GNUmakefile'.
  Trying implicit prerequisite 'RCS/GNUmakefile,v'.
  Trying pattern rule with stem 'GNUmakefile'.
  Trying implicit prerequisite 'RCS/GNUmakefile'.
  Trying pattern rule with stem 'GNUmakefile'.
  Trying implicit prerequisite 's.GNUmakefile'.
  Trying pattern rule with stem 'GNUmakefile'.
  Trying implicit prerequisite 'SCCS/s.GNUmakefile'.
  Trying pattern rule with stem 'GNUmakefile'.
  Trying implicit prerequisite 'GNUmakefile.o'.
  Looking for a rule with intermediate file 'GNUmakefile.o'.
   Avoiding implicit rule recursion.
   Trying pattern rule with stem 'GNUmakefile'.
   Trying implicit prerequisite 'GNUmakefile.cpp'.
   Trying pattern rule with stem 'GNUmakefile'.
   Trying implicit prerequisite 'GNUmakefile.c'.
   Trying pattern rule with stem 'GNUmakefile'.
   Trying implicit prerequisite 'GNUmakefile.cc'.
   Trying pattern rule with stem 'GNUmakefile'.
   Trying implicit prerequisite 'GNUmakefile.C'.
   Trying pattern rule with stem 'GNUmakefile'.
   Trying implicit prerequisite 'GNUmakefile.p'.
   Trying pattern rule with stem 'GNUmakefile'.
   Trying implicit prerequisite 'GNUmakefile.f'.
   Trying pattern rule with stem 'GNUmakefile'.
   Trying implicit prerequisite 'GNUmakefile.F'.
   Trying pattern rule with stem 'GNUmakefile'.
   Trying implicit prerequisite 'GNUmakefile.m'.
   Trying pattern rule with stem 'GNUmakefile'.
   Trying implicit prerequisite 'GNUmakefile.r'.
   Trying pattern rule with stem 'GNUmakefile'.
   Trying implicit prerequisite 'GNUmakefile.s'.
   Trying pattern rule with stem 

Re: GNU make troubleshooting

[Jeffrey Walton]

On Tue, Jul 11, 2023 at 9:44 AM Paul Smith  wrote:
>
> On Mon, 2023-07-10 at 17:17 -0400, Jeffrey Walton wrote:
> > Yes, lots of conditionals and lots of shell'ing, like:
> >
> > GREP ?= grep
> > SED ?= sed
> >
> > ifneq ($(wildcard /usr/xpg4/bin/grep),)
> >   GREP := /usr/xpg4/bin/grep
> > endif
> > ifneq ($(wildcard /usr/xpg4/bin/sed),)
> >   SED := /usr/xpg4/bin/sed
> > endif
> >
> > SUN_COMPILER := $(shell $(CXX) -V 2>&1 | $(GREP) -i -c -E 'CC:
> > (Sun|Studio)')
> > GCC_COMPILER := $(shell $(CXX) --version 2>/dev/null | $(GREP) -v -E
> > '(llvm|clang)' | $(GREP) -i -c -E '(gcc|g\+\+)')
> > XLC_COMPILER := $(shell $(CXX) -qversion 2>/dev/null |$(GREP) -i -c
> > "IBM XL")
> > CLANG_COMPILER := $(shell $(CXX) --version 2>/dev/null | $(GREP) -i -
> > c
> > -E '(llvm|clang)')
> > INTEL_COMPILER := $(shell $(CXX) --version 2>/dev/null | $(GREP) -i -
> > c
> > '\(icc\)')
> > ...
>
> But, what about this do you want to know?

I want to see an output for the evaluation of each statement, like
what I would see with 'set -x'. I need to know where something goes
sideways when shell'ing out in a pipe.

> If what you want to know is "what was the result of all this", the
> database print (-p) option will show you what make computed as the
> final value for each of these variables, and also what linenumber of
> the makefile was used to set the final version:
>
>   # makefile (from 'Makefile', line 12)
>   GCC_COMPILER := 0
>...
>   # makefile (from 'Makefile', line 1)
>   GREP = grep
>...
>
> I don't want to suggest that everything is just peachy.  There are lots
> of rough edges for working with GNU Make and Makefiles, there is no
> question about that.  I'm just trying to understand clearly what things
> will actually be useful, rather than simply spewing out more output
> similar to what -d does.

Here's 'make -d' for a project I help maintain. No info on the
evaluations shown above, which would be useful to me. There is lots of
information that looks like it would be useful to a GNU Make
maintainer.

$ make -d
GNU Make 4.3
Built for x86_64-pc-linux-gnu
Copyright (C) 1988-2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Reading makefiles...
Reading makefile 'GNUmakefile'...
Updating makefiles
 Considering target file 'GNUmakefile'.
  Looking for an implicit rule for 'GNUmakefile'.
  Trying pattern rule with stem 'GNUmakefile'.
  Trying implicit prerequisite 'GNUmakefile.o'.
  Trying pattern rule with stem 'GNUmakefile'.
  Trying implicit prerequisite 'GNUmakefile.c'.
  Trying pattern rule with stem 'GNUmakefile'.
  Trying implicit prerequisite 'GNUmakefile.cc'.
  Trying pattern rule with stem 'GNUmakefile'.
  Trying implicit prerequisite 'GNUmakefile.C'.
  Trying pattern rule with stem 'GNUmakefile'.
  Trying implicit prerequisite 'GNUmakefile.cpp'.
  Trying pattern rule with stem 'GNUmakefile'.
  Trying implicit prerequisite 'GNUmakefile.p'.
  Trying pattern rule with stem 'GNUmakefile'.
  Trying implicit prerequisite 'GNUmakefile.f'.
  Trying pattern rule with stem 'GNUmakefile'.
  Trying implicit prerequisite 'GNUmakefile.F'.
  Trying pattern rule with stem 'GNUmakefile'.
  Trying implicit prerequisite 'GNUmakefile.m'.
  Trying pattern rule with stem 'GNUmakefile'.
  Trying implicit prerequisite 'GNUmakefile.r'.
  Trying pattern rule with stem 'GNUmakefile'.
  Trying implicit prerequisite 'GNUmakefile.s'.
  Trying pattern rule with stem 'GNUmakefile'.
  Trying implicit prerequisite 'GNUmakefile.S'.
  Trying pattern rule with stem 'GNUmakefile'.
  Trying implicit prerequisite 'GNUmakefile.mod'.
  Trying pattern rule with stem 'GNUmakefile'.
  Trying implicit prerequisite 'GNUmakefile.sh'.
  Trying pattern rule with stem 'GNUmakefile'.
  Trying implicit prerequisite 'GNUmakefile,v'.
  Trying pattern rule with stem 'GNUmakefile'.
  Trying implicit prerequisite 'RCS/GNUmakefile,v'.
  Trying pattern rule with stem 'GNUmakefile'.
  Trying implicit prerequisite 'RCS/GNUmakefile'.
  Trying pattern rule with stem 'GNUmakefile'.
  Trying implicit prerequisite 's.GNUmakefile'.
  Trying pattern rule with stem 'GNUmakefile'.
  Trying implicit prerequisite 'SCCS/s.GNUmakefile'.
  Trying pattern rule with stem 'GNUmakefile'.
  Trying implicit prerequisite 'GNUmakefile.o'.
  Looking for a rule with intermediate file 'GNUmakefile.o'.
   Avoiding implicit rule recursion.
   Trying pattern rule with stem 'GNUmakefile'.
   Trying implicit prerequisite 'GNUmakefile.cpp'.
   Trying pattern rule with stem 'GNUmakefile'.
   Trying implicit prerequisite 'GNUmakefile.c'.
   Trying patter

Re: GNU make troubleshooting

[Jeffrey Walton]

On Mon, Jul 10, 2023 at 4:45 PM Paul Smith  wrote:
>
> [...]
> > That's like peppering a program with printf's. I would like to
> > understand why a statement was (or was not) evaluated, and if
> > evaluated the result, but there is no option with the effect of
> > Bash's 'set +x'.
>
> I think I don't quite understand this.  Basically EVERY line in make is
> always evaluated, unless it's inside an if-statement.  Makefiles are
> not like shell scripts, where you can skip sections or return early
> before some parts are parsed.  The entire makefile is parsed before any
> rules are invoked.

Yes, lots of conditionals and lots of shell'ing, like:

GREP ?= grep
SED ?= sed

ifneq ($(wildcard /usr/xpg4/bin/grep),)
  GREP := /usr/xpg4/bin/grep
endif
ifneq ($(wildcard /usr/xpg4/bin/sed),)
  SED := /usr/xpg4/bin/sed
endif

SUN_COMPILER := $(shell $(CXX) -V 2>&1 | $(GREP) -i -c -E 'CC: (Sun|Studio)')
GCC_COMPILER := $(shell $(CXX) --version 2>/dev/null | $(GREP) -v -E
'(llvm|clang)' | $(GREP) -i -c -E '(gcc|g\+\+)')
XLC_COMPILER := $(shell $(CXX) -qversion 2>/dev/null |$(GREP) -i -c "IBM XL")
CLANG_COMPILER := $(shell $(CXX) --version 2>/dev/null | $(GREP) -i -c
-E '(llvm|clang)')
INTEL_COMPILER := $(shell $(CXX) --version 2>/dev/null | $(GREP) -i -c
'\(icc\)')
...

Jeff

Re: GNU make troubleshooting

[Jeffrey Walton]

On Mon, Jul 10, 2023 at 2:32 PM Bruno Haible  wrote:
>
> In recent build system discussions on gnu-prog-discuss, the suggestion was
> made [1] to use GNU make's power instead of autoconf, automake, and POSIX 
> make.
>
> I think GNU make is lacking transparency / debuggability / serviceability
> features before this suggestion makes sense. Especially for newbie users
> and complex makefiles.
>
> I know about, and have occasionally used, the GNU make options
>   -n, --dry-run
>   -d
>   -p
>   -t, --touch
> and they don't fulfil my needs.
>
> In particular, four aspects of transparency / debuggability / serviceability
> are lacking in GNU make.
>
> 1) Print the total of the Makefile and all included Makefiles.
>Like what "gcc -E" does with C code.
>I don't need this when using Automake, because Automake resolves the
>'include' statements before generating a Makefile. But if people advocate
>to use GNU make without Automake, it becomes a requirement. As a developer,
>I don't want to check each 'include' statement, recursively, manually.
>A tool should do that.
>
>This would also answer a question on #gnu today:
>"Is there a way to figure out where the rule is coming from? The main
> issue is "target file 'clean' has both : and :: entries. Stop." But
> I'm unable to figure out where the last clean: target is coming from."
>
>Probably this facility should have an option to show the macroexpanded /
>not macroexpanded Makefile sources.
>
> 2) Where is the Makefile source for each command that gets executed?
>For each command that gets executed, print not only the command (or
>nothing if the line begins with '@'), but also the location (which
>Makefile, which line number).
>
>This would help in a number of situations.
>
>I tried -d a couple of times, and it produced a ton of output, that
>was too much for me to make sense of. Probably 10% to 20% of the
>developers in general have trace filtering skills, that is, know how
>to extract the essential information from a heap of output. It's not
>part of my skills.
>
> 3) Single-stepping or tracing function execution. One project (GNU libc)
>makes profound use of GNU make functions, and it was always painful
>for me to understand what results to expect from a complex use of
>$(foo ...). Even from the simple text-manipulating functions [2].
>
>There is an option --eval=STRING, but I don't think it fulfils the
>need.
>
> 4) A documentation chapter regarding troubleshooting, that explains
>how to understand what 'make' is doing in a particular case.
>Chapters 2-8 and 10-12 explain how to set up the input to 'make'.
>Chapters 9 and 13 explain operational aspects, but none goes into
>troubleshooting details.
>For a complex program like GNU make, probably at least 10 or 20 pages
>on this topic are needed.
>
> Best regards,
>
> Bruno
>
> [1] https://www.airs.com/blog/archives/95
> [2] https://www.gnu.org/software/make/manual/html_node/Functions.html

I think GNU Make provides all you need for feature testing in C/C++
programs. I don't know about other languages, like Fortran.
I use GNU Make all the time for C/C++ programs in place of Autotools,
CMake and friends.

I would add GNU's make lacks minimal debug facilities. I don't
consider '$(info ...)' debugging. That's like peppering a program with
printf's. I would like to understand why a statement was (or was not)
evaluated, and if evaluated the result, but there is no option with
the effect of Bash's 'set +x'.

I think trace is worthless. It does not help the folks writing
makefiles. Or it has never helped me understand why a statement was
(or was not) evaluated, or the result of the evaluation.

Jeff

Re: CentOS Stream installation

[Jeffrey Walton]

On Sun, Feb 5, 2023 at 5:06 PM Paul Smith  wrote:
> [...]
> > I never install the VirtualBox guest additions. The downside is that
> > sharing data is less comfortable (I use 'scp' each time), and that
> > the mouse handling is a bit more annoying.
>
> The problem is that I can't seem to open connections from my host
> machine to the guest machine: my host machine can't find the guests via
> any IP address I can come up with.

In Virtual Box, setup the LAN adapter as bridged. It will get an
address from your DHCP server, and you will be able to SSH to it.

The wrinkle is, if your host is connected via wifi. If your host is
wifi connected, then guests cannot use bridging to get a DHCP address.
In this case, use an ethernet/usb adapter for the host. Then the
bridged adapter will be available.

Jeff

Re: GNU/Hurd installation

[Jeffrey Walton]

On Sun, Jan 15, 2023 at 3:04 PM Paul Smith  wrote:
>
> On Sun, 2023-01-15 at 19:24 +0100, Bruno Haible wrote:
> > Pseudo-graphical install.
>
> I've tried a couple of times, using different instructions (VirtualBox
> and vanilla KVM) and every time when it starts to boot the first time
> (after selecting this install) it prints:
>
>   ...
>   module 0: initrd $(ramdisk-create)
>   rd0: 13279232 bytes @fa491
>   module 1: ext2fs ...
>   module 2: exec $(exec-task=task-create)
>   3 multiboot modules
>   task loaded: ext2fs ...
>   zip:device:rd0
>   task loaded: exec
>
>   start ext2fs: _
>
> and hangs there.  No files appear to be updated on my disk in the
> VirtualBox directory.  The first time I got a "program appears to be
> unresponsive" after a few minutes, and killed it.
>
> It has already been hung for >10 minutes but I will let it go longer to
> see what happens.

Installation of Hurd has been failing for me since 2019. I think
Samuel is overworked, and he could use a hand at times. See
https://lists.debian.org/debian-hurd/2019/02/msg3.html .

Jeff

Re: [doc] MAKEOVERRIDES is undocumented

[Jeffrey Walton]

On Mon, Dec 19, 2022 at 1:53 PM Alejandro Colomar
 wrote:
>
> On 12/19/22 19:18, Dmitry Goncharov wrote:
> > On Mon, Dec 19, 2022 at 11:24 AM Jeffrey Walton  wrote:
> >> For the *.pc file, we need '$(prefix)' to survive unexpanded.
> >
> > What about
> > includedir:=$${prefix}/include
> > myconfig.pc:; @echo 'includedir=$(includedir)' >> myconfig.pc
>
> That would render the $(includedir) variable unusable for use within the
> Makefile (for example, within targets that install the header files).

Yep, that's why we track both includedir and pc_includedir.

Jeff

Re: [doc] MAKEOVERRIDES is undocumented

[Jeffrey Walton]

On Mon, Dec 19, 2022 at 11:22 AM Paul Smith  wrote:
>
> On Mon, 2022-12-19 at 10:57 -0500, Jeffrey Walton wrote:
> >ifeq ($(includedir),)
> >  includedir := $(prefix)/include
> >  PC_INCLUDEDIR = $${prefix}/include
> >else
> >  PC_INCLUDEDIR = $(includedir)
> >endif
>
> Maybe I'm misunderstanding some subtlety here but why not just:
>
>   includedir := $(prefix)/include
>   PC_INCLUDEDIR = $(includedir)

For the *.pc file, we need '$(prefix)' to survive unexpanded.

Jeff

Re: [doc] MAKEOVERRIDES is undocumented

[Jeffrey Walton]

On Mon, Dec 19, 2022 at 10:45 AM Alejandro Colomar
 wrote:
>
> I needed to use MAKEOVERRIDES for updating a pkgconf (.pc) file.  I want it to
> have the correct directory variables as used when building/installing the
> library, so if the user specifies 'includedir=/foo/bar' in the command line, 
> the
> .pc file should be updated with that info.
>
> The rule I had to use is:
>
> $(_LIB_pc): $(_LIB_pc_u) Makefile | $$(@D)/
> $(info  SED $@)
> sed 's/Version:.*/Version: $(DISTVERSION)/' <$< >$@
> sed -i 's,prefix=.*,prefix=$(prefix),' $@
> ifneq ($(filter includedir=%,$(MAKEOVERRIDES)),)
> sed -i 's,includedir=.*,includedir=$(includedir),' $@
> endif
>
> As you can see, I need to check if it was overridden in the command line
> (otherwise, the default 'includedir=${prefix}/include' in the .pc file is 
> fine).
>   And then I do override it.

I don't think you need to go to extremes. Just check if includedir is
set. If so, use it. If not, use the default of $prefix/include.

You can do this in your makefile [1,2]:

   ifeq ($(includedir),)
 includedir := $(prefix)/include
 PC_INCLUDEDIR = $${prefix}/include
   else
 PC_INCLUDEDIR = $(includedir)
   endif

myconfig.pc:
...
   @echo 'includedir=$(PC_INCLUDEDIR)' >> myconfig.pc

Jeff

[1] https://github.com/weidai11/cryptopp/blob/master/GNUmakefile#L202
[2] https://github.com/weidai11/cryptopp/blob/master/GNUmakefile#L1544

Re: [bug #63516] `include` of absolute path prepends path with `./`

[Jeffrey Walton]

On Thu, Dec 15, 2022 at 4:17 PM anonymous  wrote:
>
> Follow-up Comment #4, bug #63516 (project make):
>
> I've attached my fix in case it's helpful.  Also attached is a small fix to
> `bootstrap.bat` that I had to make to get it to build with `tcc`.
>
> (file #54105, file #54106)

Regarding this from the make part of the patch:

+is_abs = is_abs && path[2] && (path[2] == '/');

Isn't it possible to use Windows path separator in one of the ports by
escaping the backslash? I.e., you may encounter 'C:\\..." in the wild?

(I generally don't use *nix on Windows. But I think there's some
differences among MinGW, Cygwin and MSYS2, and permissible path
separators).

Jeff

Re: [bug #63330] readdir() error in 4.4 on Solaris 8

[Jeffrey Walton]

On Tue, Nov 8, 2022 at 10:40 AM Dmitry Goncharov
 wrote:
>
> Follow-up Comment #9, bug #63330 (project make):
>
> Depending on _LARGEFILE64_SOURCE and _FILE_OFFSET_BITS dirent has d_ino and
> d_off fields 32 or 64 bits wide.
> Looks like in your case the remote machine has 64bit d_ino and d_off and make
> is built with 32bit d_ino and d_off.
>
> i don't see checks for _FILE_OFFSET_BITS in your config.log.
> Does make work if you build 64 bit or set -D_FILE_OFFSET_BITS=64?
> What is the difference, in regards to large file support, between your good
> working make-4.3 config.log and config.status and this one that fails?
>
> In regards to the error see
> https://docs.oracle.com/cd/E19455-01/806-1075/msgs-2215/index.html

If I recall correctly, Sun recommends building 64-bit binaries on
64-bit OSes, but AutoTools still defaults to 32-bit builds on the
platform.

>From https://docs.oracle.com/cd/E37838_01/html/E66175/features-1.html :

All new applications must be developed as 64-bit
applications and many of the existing 32-bit applications
might require conversion to 64-bit.

Jeff

Re: [bug #63330] readdir() error in 4.4 on Solaris 8

[Jeffrey Walton]

On Tue, Nov 8, 2022 at 8:16 AM anonymous  wrote:
>
> Follow-up Comment #8, bug #63330 (project make):
>
> Just checked and this also affects Solaris 10.  The issue looks identical, let
> me know if you want details from that system.

For testing, gcc210 at the Compile Farm is Solaris 10. See
https://cfarm.tetaneutral.net/machines/list/ .

Jeff

Re: [PATCH] Bad timestamps on MinGW32

[Jeffrey Walton]

On Wed, Nov 2, 2022 at 4:15 PM Orgad Shaneh  wrote:
>
> On Wed, Nov 2, 2022 at 7:04 PM Eli Zaretskii  wrote:
> > > Fix by enabling _stat64 also for MinGW.
> >
> > Thanks, but this cannot be done for all MinGW builds.  There's
> > mingw.org's MinGW (which is what I use), and its default is to use
> > 32-bit time_t values.  If you use this change with that MinGW, Make
> > will likely crash at run time, because various libraries it is linked
> > against use a different time_t in stat calls.
>
> Hi, and thanks for the prompt reply.
>
> Do you mean that __MINGW_USE_VC2005_COMPAT has no effect on this
> platform? Or that it doesn't support _stat64? Or something else?
>
> > So this condition:
> >
> > > -#if defined(_MSC_VER) && _MSC_VER > 1200
> > > +#if defined(__MINGW32__) || (defined(_MSC_VER) && _MSC_VER > 1200)
> >
> > must be rewritten to catch only MinGW64 builds.  Which would mean a
> > more fine-grained testing of the value of __MINGW_MAJOR_VERSION etc.
>
> I'll try to find something. But first I'll need an answer for the
> previous question, so I know which changes to look for in mingw.

You might also be interested in __MINGW64__.

I don't think it's a good idea to try to use MinGW or compiler
versions as a proxy for 32- or 64-bit time_t. Things are in flux to
fix the y2038 problem. The debian-arm and debian-powerpc lists are
having discussions about it now. You will surely encounter 64-bit
time_t on 32-bit machines eventually.

A first class configure test that checks for the size of time_t will
probably be your best choice.

Jeff

Re: Missing [/usr/local]/var/lib and [/usr/local]/tmp

[Jeffrey Walton]

On Mon, Jul 18, 2022 at 10:22 AM Bruno Haible  wrote:
>
> Jeffrey Walton wrote:
> > I believe MacOS maps /etc and /tmp to a private area for the user.
> > They are not world readable/writable. I believe Apple did it for
> > hardening.
> >
> > Here's from a MacOS X 10.5 machine I have:
> >
> > $ ls -l /etc /tmp
> > lrwxr-xr-x@ 1 root  wheel  11 Feb 10  2015 /etc -> private/etc
> > lrwxr-xr-x@ 1 root  wheel  11 Feb 10  2015 /tmp -> private/tmp
>
> /tmp is world-writable, of course:
>
> $ ls -lLd /etc /tmp
> drwxr-xr-x@ 124 root  wheel  3968 27 Jun 01:25 /etc
> drwxrwxrwt@   8 root  wheel   256 18 Jul 14:38 /tmp

I believe Apple creates a copy of /etc, /var and /tmp for the user.
Then, writes occur to the private area the OS provides to the user. I
don't believe users are allowed to write directly to those
directories. In the old days it happened because of NetBoot. Nowadays
it's because of Apple's System Integrity Protection.

Also see 
https://apple.stackexchange.com/questions/1043/why-is-tmp-a-symlink-to-private-tmp
and https://en.wikipedia.org/wiki/System_Integrity_Protection .

Jeff

Re: Missing [/usr/local]/var/lib and [/usr/local]/tmp

[Jeffrey Walton]

On Mon, Jul 18, 2022 at 8:18 AM Edward Welbourne  wrote:
>
> Alejandro Colomar (Monday, July 18, 2022 14:07)
> > MacOS seems to be setting TMPDIR (or at least some script run at
> > startup seems to be setting it in my system), and it's set to something
> > really weird that I don't trust will exist after reboot.
>
> Then I think the way you're using tmpdir doesn't match its usual
> semantics, namely that it's exactly a directory that's routinely blown
> away and recreated, at least as often as boot-time and ideally more
> often.  If what you need is a place to store (even semi-) persistent
> state for a program, that should survive reboots, then you want
> $prefix/var/, not /tmp/ (which may well be a tmpfs partition, indeed).

I believe MacOS maps /etc and /tmp to a private area for the user.
They are not world readable/writable. I believe Apple did it for
hardening.

Here's from a MacOS X 10.5 machine I have:

$ ls -l /etc /tmp
lrwxr-xr-x@ 1 root  wheel  11 Feb 10  2015 /etc -> private/etc
lrwxr-xr-x@ 1 root  wheel  11 Feb 10  2015 /tmp -> private/tmp

Jeff

Re: [bug #62173] Fix test features/archives.

[Jeffrey Walton]

On Sun, Mar 13, 2022 at 10:49 AM Dmitry Goncharov
 wrote:
>
> Follow-up Comment #2, bug #62173 (project make):
>
> The patch contains the following changes
> 
> -my $arflags = 'rv';
> +my $arflags = '-rv';
> +if ($^O eq 'aix') {
> +$arflags = "-Xany -rv";
> +}
> 
>
> That reason for the first part of the patch, specifically
> 
> -my $arflags = 'rv';
> +my $arflags = '-rv'
> 
> is the following
>
> The test has the following piece of code
>
> 
> $_ = `$ar U$arflags libxx.a a1.o $redir`;
> if ($? == 0) {
> $arflags = 'Urv';
> $arvar = "$arvar ARFLAGS=$arflags";
> }
> 
>
> This piece of code causes $arvar contain $arflags.
> This happens only when ar supports -U. This is relatively new version of gnu
> ar.
> Other systems (not only aix) won't have ar support -U and $arvar on those
> systems does not contain $arflags. The default value of ARFLAGS builtin in
> make was change from 'rv' to -rv' in 0e020bbc24d89592e9ea15f9e8b887a71692eedf.
> This makes the test fail on any system where ar does not support -U.
>
> The other part of the patch, specifically
> 
> +if ($^O eq 'aix') {
> +$arflags = "-Xany -rv";
> +}
> 
> is indeed aix specific. I originally proposed to use an env var OBJECT_MODE
> and keep arflags intact on aix (see sv 59096). But that robs the user of the
> ability to override the value.
> However, i'd call this change trivial.
>
>
>
> > I have quite a few of similar issues with the test suite on MS-Windows, but
> I never thought I should make changes non-trivial to the test suite to make
> those pseudo-failures pass.  Instead, I eyeball the test diffs to determine
> whether the issue is real or not.
>
> i once had to make a change which affected windows (sv 60774). Once i was able
> to build make, i wanted to check that the test suite passes. It did not. i am
> not familiar with windows. i'd definitely appreciate if the test suite passed.
> Similarly, if you ever have to make a change on sun or aix, etc, you'll
> appreciate if the test suite passes.

Be sure to test the change on OpenBSD. In the past OpenBSD needed the
dash for options. I'm not sure if it is needed nowadays.

Jeff

Re: sub makefile does not use correct value of CFLAGS from top make file,

[Jeffrey Walton]

On Fri, Sep 3, 2021 at 5:58 PM Jeffrey.Fellin--- via Bug reports and
discussion for GNU make  wrote:
>
> I have a project that compiles .S and .c files, and the value of CFLAGS in 
> the sub makefile is not the same for the compile lines
> ...
> The compile of bug.S succeeds, but doesn’t have the correct value of CFLAGS, 
> as in the annotated output below. The compile of hello.c has the correct 
> value of CFLAGS, but the compile fails due to the unsupported options to the 
> cc. The extra options are for use by the project specific compiler.

I believe you should use ASFLAGS for assembly source, not CFLAGS.

Also see "Variables Used by Implicit Rules"
(https://ftp.gnu.org/old-gnu/Manuals/make-3.79.1/html_node/make_97.html)
in the manual.

Jeff

Re: Keeping intermediate files

[Jeffrey Walton]

On Thu, May 20, 2021 at 4:29 PM Frank Heckenbach
 wrote:
>
> Is there are way to completely stop GNU make from removing
> intermediate files?

Related, you usually ask the compiler to save the intermediate files.
For GCC the option is -save-temps. Also see
https://gcc.gnu.org/onlinedocs/gcc/Overall-Options.html.

Jeff

Re: [bug #47880] Allow updates to .INCLUDE_DIRS to change search path

[Jeffrey Walton]

On Sun, Apr 25, 2021 at 10:51 AM Dmitry Goncharov
 wrote:
>
> Follow-up Comment #9, bug #47880 (project make):
>
> > But, maybe it's better to grab that bull by the horns.
>
> From the user's point of view, it may indeed be better to have a single
> interface (MAKEFLAGS), which controls the behavior from the makefile.

I think there's a MAKEOPTS already.

Jeff

Re: GNU Make 4.3: Makefile rule spooky action at a distance

[Jeffrey Walton]

On Sun, Oct 4, 2020 at 9:32 AM Danny Milosavljevic
 wrote:
>
> Hi,
>
> I just got a build failure in lz4.  I've isolated it and made a minimal test 
> case, see below.
>
> This is on GNU Guix on a x86_64 machine.
>
> The reason is that apparently one Makefile rule can unwittingly change how 
> another unrelated rule functions, IF a submake is involved.
>
> To reproduce:
>
> $ cat Makefile
>
> all:
> $(MAKE) -C foo all
>
> dummy: CFLAGS ?= bar
> dummy:
>
> $ cat foo/Makefile
>
> CFLAGS ?= internal
>
> all:
> echo $(CFLAGS)
>
> Expected behavior:
>
> $ CFLAGS=ok make
> make -C foo all
> make[1]: Entering directory 'foo'
> echo ok
> ok
> make[1]: Leaving directory 'foo'
>
> Actual behavior:
>
> $ CFLAGS=ok make
> make -C foo all
> make[1]: Entering directory 'foo'
> echo internal
> internal
> make[1]: Leaving directory 'foo'

I think you need to export CFLAGS. Or that is where I would look.
CFLAGS is set in the first shell, but it is not inherited in child
shells.

Or, the top makefile should do something like:

all:
$(MAKE) -C foo all CFLAGS=$(CFLAGS)

Jeff

Help wanted from 2003

[Jeffrey Walton]

This makes me smile. A GNU Make help wanted ad from 2003:
http://savannah.nongnu.org/people/index.php?categories[]=1

What causes "No rule to make target 'crypto/(0x55ae24c35998).o'"

[Jeffrey Walton]

Hi Everyone,

I'm working with OpenSSL sources, and trying to port OpenSSL tomodern
Android NDKs. I'm not familiar with their makefiles) other than they
are messy). My fork is at
https://github.com/noloader/openssl/tree/android.

The Travis jobs are failing with an error like shown below. An error
result is at https://travis-ci.org/github/noloader/openssl/jobs/661708091.

aarch64-linux-android26-clang  -I. -Iinclude -Iapps/include  -fPIC -pthread -Wa,
--noexecstack -Qunused-arguments -funwind-tables -fexceptions --sysroot=/home/tr
avis/android-ndk/toolchains/llvm/prebuilt/linux-x86_64/sysroot -DOPENSSL_USE_NOD
ELETE -DOPENSSL_BUILDING_OPENSSL -DOPENSSL_PIC -DOPENSSLDIR="\"/home/travis/andr
oid26-aarch64\"" -DENGINESDIR="\"/home/travis/android26-aarch64/lib/engines-3\""
 -DMODULESDIR="\"/home/travis/android26-aarch64/lib/ossl-modules\"" -DNDEBUG -D_
_ANDROID_API__=26 -MMD -MF apps/lib/libapps-lib-s_socket.d.tmp -MT apps/lib/liba
pps-lib-s_socket.o -c -o apps/lib/libapps-lib-s_socket.o apps/lib/s_socket.c

make[1]: *** No rule to make target 'crypto/(0x55ae24c35998).o',
needed by 'libcrypto.a'.  Stop.

The error message is the first mention of 0x55ae24c35998. It does not
show up in a compile command.

What causes a "No rule to make target 'crypto/(0x55ae24c35998).o'" error?

Thanks in advance.

Jeff

No rule to make ?

[Jeffrey Walton]

Hi Everyone,

I'm having trouble figuring out this problem. I can build fine from
the command line, but I'm catching an error:

make: *** No rule to make target 'libcrypto.a', needed by
'test2.exe'.  Stop.

I have a simple makefile:

$ cat Makefile
all: test.exe test2.exe

LIBCRYPTO = -l:libcrypto.a

test.exe:
$(CXX) $(CXXFLAGS) -g2 -O0 -o test.exe test.cxx -pthread $(LIBCRYPTO) -ldl

test2.exe:
$(CXX) $(CXXFLAGS) -g2 -O0 -o test2.exe test2.cxx -pthread
$(LIBCRYPTO) -ldl

But this works just fine:

$ g++ -o test2.exe -g2 -O0 test2.cxx -l:libcrypto.a -pthread -ldl
$

Any ideas why Make is trying to build a system library?

Jeff

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Idea: Automatically correct timestamps

[Jeffrey Walton]

On Sun, Jun 9, 2019 at 10:38 PM Paul Smith  wrote:
> On Sun, 2019-06-09 at 18:24 -0400, David A. Wheeler wrote:
> > ...
> > In many cases I suspect this would eliminate calls for using md5
> > hashes and special state; I suspect many of those requests are really
> > trying to deal with problems of clock slew that this proposal
> > resolves.
>
> Hm.  Maybe people have just given up reporting this problem but
> honestly I can't remember the last time I had anyone ask questions here
> or on StackOverflow that are related to clock skew.  I sort of thought
> it was a solved problem.
>
> Most of the requests I see these days that would require a "last state
> database" wouldn't be helped by md5 checks: mainly they're asking for
> things like rebuilding targets automatically when compiler options have
> changed etc.  Things like that can be done today with a lot of fancy
> trickery but people would rather it "just worked".

+1. I'd welcome a make that is aware of option changes. It has jumped
up and bit me several times over the years.

Clock skew is another problem I seem to often encounter after editing
a source file on one machine, and then scp'ing to another machine. If
the db helps with this problem, then it is killing two birds with one
stone.

Jeff

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Memory leaks in Make

[Jeffrey Walton]

On Tue, May 14, 2019 at 10:40 PM Martin Dorey
 wrote:
>
> > It would be nice if Make cleaned up its resources before exiting.
>
> Would it?  Linking all those blocks back on to free lists and coalescing 
> adjacent ones doesn't take a long time but it takes more time than just 
> tearing down the address space.  It can be a reasonable economy for 
> short-lived processes not to clean up before exiting.  Recursive make might 
> be considered harmful but it's still a common use-case with such short-lived 
> processes.

Interesting you bring up economic models for this. I've given that
quite a bit of thought, and even researched the numbers.

  * 25 million programmers in the world
  * 6 - 12 % are C and C++, depending on the source
  * 3 million QA folks in the world

That means there's a potential pool of (25M+3M) * 0.09 = 2.5 million
folks. Suppose 1/1000 perform acceptance testing, security testing and
evaluation, etc. That means about 3000 folks are experiencing this
problem.

I spent 5 days trying to test IDN and IDN2. It was not just the
LD_PRELOAD hail mary. It included a lot of other troubleshooting and
tinkering trying to get IDN and IDN2 to test.

Assume it takes the Make project 3 days to make the necessary changes
to avoid the leak. 3 days is 24 man-hours, and that beats the work I
put in by 16 hours. Assume the other 3000 folks try and give up after
a day. The world has spent 24000 man-hours on a problem that could
have been cleared in 3 days.

Which makes more sense to you? The Make project spending 3 days to fix
the problem, or the world servicing your technological debt at the
cost of 24,000 man hours or 11 man-years?

> > It looks like Make's memory leaks are killing the build process long before 
> > the test runners execute.
>
> I presume you have some compelling evidence for that and I appreciate not 
> being deluged with large attachments...

Yes, I have the build results that starts with 'make check', and end with:

gmake: *** [Makefile:1495: check-recursive] Error 1
Failed to test IDN

Not one test was run because the tools failed.

> but the trouble with what you have shared is that 89 bytes leaked in total 
> seems like it wouldn't be a problem for even the smallest system.

It taints results of other components. It does not matter if it is a 1
byte leak.

Jeff

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Memory leaks in Make

[Jeffrey Walton]

Hi Everyone,

My apologies if I raised this issue already. I did not see it in the
archives at https://lists.gnu.org/archive/html/bug-make/2019-04/index.html
or https://lists.gnu.org/archive/html/bug-make/2019-05/index.html .

I'm trying to test libidn with Asan, which is used for
internationalized domain names. IDN also uses Gnulib and Gnulib is
resisting testing. I can build everything with -fsanitize=address, but
Gnulib test runners are doing something such that libasan.so is not
being loaded properly. It results in all tests runners failing.

The work-around is to LD_PRELOAD libasan.so. Unfortunately for me,
that means I have to LD_PRELOAD on the invocation of make. So,
running:

LD_PRELOAD=/lib64/libasan.so.5 make check

Results in:

=
==19205==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 56 byte(s) in 1 object(s) allocated from:
#0 0x7feb1d6e1c08 in __interceptor_malloc (/lib64/libasan.so.5+0xefc08)
#1 0x55f2ff6d2778 in xmalloc (/usr/bin/make+0x1d778)

Indirect leak of 33 byte(s) in 1 object(s) allocated from:
#0 0x7feb1d62de60 in strdup (/lib64/libasan.so.5+0x3be60)
#1 0x55f2ff6d29ec in xstrdup (/usr/bin/make+0x1d9ec)

SUMMARY: AddressSanitizer: 89 byte(s) leaked in 2 allocation(s).

It looks like Make's memory leaks are killing the build process long
before the test runners execute.

It would be nice if Make cleaned up its resources before exiting. The
leaks are affecting other components, and they have halted Asan
testing for this unit. LD_PRELOAD was my last chance to test this
library, and I don't seem to have any other alternatives.

I'm working on Fedora 29 with Make 4.2.1, but I have a feeling
platform and versions do not matter.

Jeff

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: __alloca patch?

[Jeffrey Walton]

On Sat, May 4, 2019 at 4:34 PM Jeffrey Walton  wrote:
>
> On Sat, May 4, 2019 at 3:14 PM Paul Smith  wrote:
> >
> > On Sat, 2019-05-04 at 15:10 -0400, Jeffrey Walton wrote:
> > > Ack, thanks. It works perfectly on Fedora 29.
> > >
> > > This was a good change:
> > >
> > > -# if _GNU_GLOB_INTERFACE_VERSION == GLOB_INTERFACE_VERSION
> > > +# if _GNU_GLOB_INTERFACE_VERSION == 1 || _GNU_GLOB_INTERFACE_VERSION == 2
> > >
> > > I found the one discussed on the mailing list and used it. But it
> > > looks like it was wrong:
> > >
> > > # if _GNU_GLOB_INTERFACE_VERSION >= GLOB_INTERFACE_VERSION
> >
> > Well, they're equivalent at the moment, but who knows what the future
> > may bring? :)
> >
> > These changes were all cherry-picked from commits already present in
> > the latest Git HEAD.  See the Git commit history for attribution.
>
> It tested OK on Solaris 11.3 also.
>
> I had to sidestep an autoreconf because Solaris provides an old
> version of Autotools. See
> https://github.com/noloader/Build-Scripts/commit/d831d99544be .

And tested OK on OS X 10.9 x86_64. This build was a tad bit noisy, but
tested OK.

gcc -DHAVE_CONFIG_H -I. -I..   -I/usr/local/include -DNDEBUG  -g2 -O2
-march=native -fPIC -pthread -MT fnmatch.o -MD -MP -MF
.deps/fnmatch.Tpo -c -o fnmatch.o fnmatch.c
glob.c:818:27: warning: incompatible pointer types passing 'char **' to
  parameter of type 'char *'; dereference with *
  [-Wincompatible-pointer-types]
= (char **) realloc (pglob->gl_pathv,
 ^~~
 *
glob.c:937:24: warning: incompatible pointer types passing 'char **' to
  parameter of type 'char *'; dereference with *
  [-Wincompatible-pointer-types]
= (char **) realloc (pglob->gl_pathv,
 ^~~
 *
...

Jeff

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: __alloca patch?

[Jeffrey Walton]

On Sat, May 4, 2019 at 3:14 PM Paul Smith  wrote:
>
> On Sat, 2019-05-04 at 15:10 -0400, Jeffrey Walton wrote:
> > Ack, thanks. It works perfectly on Fedora 29.
> >
> > This was a good change:
> >
> > -# if _GNU_GLOB_INTERFACE_VERSION == GLOB_INTERFACE_VERSION
> > +# if _GNU_GLOB_INTERFACE_VERSION == 1 || _GNU_GLOB_INTERFACE_VERSION == 2
> >
> > I found the one discussed on the mailing list and used it. But it
> > looks like it was wrong:
> >
> > # if _GNU_GLOB_INTERFACE_VERSION >= GLOB_INTERFACE_VERSION
>
> Well, they're equivalent at the moment, but who knows what the future
> may bring? :)
>
> These changes were all cherry-picked from commits already present in
> the latest Git HEAD.  See the Git commit history for attribution.

It tested OK on Solaris 11.3 also.

I had to sidestep an autoreconf because Solaris provides an old
version of Autotools. See
https://github.com/noloader/Build-Scripts/commit/d831d99544be .

Jeff

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: __alloca patch?

[Jeffrey Walton]

On Sat, May 4, 2019 at 2:45 PM Paul Smith  wrote:
>
> On Thu, 2019-05-02 at 02:13 -0400, Jeffrey Walton wrote:
> >
> > I'm working from the 4.2.1 tarball. I see __alloca has caused some
> > grief. (
> > https://lists.gnu.org/archive/html/bug-make/2017-11/msg00020.html
> >
> > and friends).
> >
> > There have been no GNU Make releases since June 2016. The problem is
> > still present, and it does not look like it is going to be fixed
> > anytime soon.
> >
> > What is the official patch to fix the problem? Does someone have a
> > 'diff -u' or a 'git diff'?
>
> Applying the attached patch to a downloaded source tarball of GNU make
> 4.2.1 should allow it to work correctly with the latest GNU libc
> versions.

Ack, thanks. It works perfectly on Fedora 29.

This was a good change:

-# if _GNU_GLOB_INTERFACE_VERSION == GLOB_INTERFACE_VERSION
+# if _GNU_GLOB_INTERFACE_VERSION == 1 || _GNU_GLOB_INTERFACE_VERSION == 2

I found the one discussed on the mailing list and used it. But it
looks like it was wrong:

# if _GNU_GLOB_INTERFACE_VERSION >= GLOB_INTERFACE_VERSION

Jeff

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

__alloca patch?

[Jeffrey Walton]

Hi Everyone,

I'm working from the 4.2.1 tarball. I see __alloca has caused some
grief. (https://lists.gnu.org/archive/html/bug-make/2017-11/msg00020.html
and friends).

There have been no GNU Make releases since June 2016. The problem is
still present, and it does not look like it is going to be fixed
anytime soon.

What is the official patch to fix the problem? Does someone have a
'diff -u' or a 'git diff'?

Thanks in advance,

Jeff

**

Here is the problem on Fedora 29 x86_64:

gmake[2]: Entering directory '/home/jwalton/Build-Scripts/make-4.2.1/glob'
gcc -DHAVE_CONFIG_H -I. -I..   -I/usr/local/include -DNDEBUG  -g2 -O2
-march=native -fPIC -MT glob.o -MD -MP -MF .deps/glob.Tpo -c -o glob.o
glob.c
gcc -DHAVE_CONFIG_H -I. -I..   -I/usr/local/include -DNDEBUG  -g2 -O2
-march=native -fPIC -MT fnmatch.o -MD -MP -MF .deps/fnmatch.Tpo -c -o
fnmatch.o fnmatch.c
mv -f .deps/fnmatch.Tpo .deps/fnmatch.Po
glob.c: In function ‘glob’:
glob.c:581:23: warning: implicit declaration of function ‘__alloca’;
did you mean ‘alloca’? [-Wimplicit-function-declaration]
   newp = (char *) __alloca (dirlen + 1);
   ^~~~
   alloca
glob.c:581:14: warning: cast to pointer from integer of different size
[-Wint-to-pointer-cast]
   newp = (char *) __alloca (dirlen + 1);
  ^
glob.c:709:15: warning: cast to pointer from integer of different size
[-Wint-to-pointer-cast]
newp = (char *) __alloca (home_len + dirlen);
   ^
glob.c:732:15: warning: cast to pointer from integer of different size
[-Wint-to-pointer-cast]
newp = (char *) __alloca (end_name - dirname);
   ^
glob.c:783:15: warning: cast to pointer from integer of different size
[-Wint-to-pointer-cast]
newp = (char *) __alloca (home_len + rest_len + 1);
   ^
glob.c:814:11: warning: implicit declaration of function ‘__stat’; did
you mean ‘__xstat’? [-Wimplicit-function-declaration]
 : __stat (dirname, )) == 0
   ^~
   __xstat
glob.c: In function ‘glob_in_dir’:
glob.c:1256:21: warning: cast to pointer from integer of different
size [-Wint-to-pointer-cast]
char *fullname = (char *) __alloca (dirlen + 1 + patlen + 1);
 ^
glob.c:1283:12: warning: cast to pointer from integer of different
size [-Wint-to-pointer-cast]
names = (struct globlink *) __alloca (sizeof (struct globlink));
^
glob.c:1341:32: warning: cast to pointer from integer of different
size [-Wint-to-pointer-cast]
 struct globlink *new = (struct globlink *)
^
glob.c:1367:15: warning: cast to pointer from integer of different
size [-Wint-to-pointer-cast]
   names = (struct globlink *) __alloca (sizeof (struct globlink));
   ^
mv -f .deps/glob.Tpo .deps/glob.Po
rm -f libglob.a
ar cru libglob.a glob.o fnmatch.o
ranlib libglob.a

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Autotools requirements are too recent

[Jeffrey Walton]

$ autoreconf -f -i
configure.ac:35: error: require Automake 1.16.1, but have 1.15.1
autoreconf: automake failed with exit status: 1

Please consider dropping version requirements. I'm working on Fedora
28. Fedora is know for having some of the most up to date tools.

If something can't build on the latest Fedora there's no hope it can
build where a newer GNU Make is truly needed, like AIX 7, OS X 10.8,
Ubuntu 12, or Solaris 11.

(In fact I test some software back to Fedora 1 with GCC 2.9 and
Windows XP with Visual Studio .Net. Those are the machines I need to
update a handful of tools on. They won't have the bleeding edge stuff
Make is embracing).

Also consider, I could not care less if I have old Autotools. I don't
care if there's a bug or race during install. I'll live with the risk.
My job is to get a new Make on the machine, not dicking around with
Autotools versions. Anything that stops me from updating Make is a
distraction and waste of energy.

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Noisy compile on Fedora 28, x86_64

[Jeffrey Walton]

On Fri, Aug 24, 2018 at 5:33 PM, Martin Dorey
 wrote:
> I think that's essentially the same issue as the failed compile one.  The
> bug I linked to there links to a mail thread that links to this mail thread:
>
> http://gnu-make.2324884.n4.nabble.com/undefined-reference-to-alloca-td18308.html
>
> If you look at Earnestly's patch there, it bears quite a resemblance to part
> of this large change:
>
> http://git.savannah.gnu.org/cgit/make.git/diff/?id=63b42fa235835cbeac6c1b9182f32798ea135dfd
>
> ... a part that went unremarked upon in the check-in comment, specifically
> the part that does "#if !defined __alloca".  Maybe you could cherry pick
> that part.  Is it really two years since the last release?

Oh my goodness... I searched for  and said WTF??? I don't
even want to know why things are done that way.

Here's what I am trying to cut-in. It is a little more tradition and
should just work.

$ git diff
diff --git a/configure.ac b/configure.ac
index 31a00a6..4480226 100644
--- a/configure.ac
+++ b/configure.ac
@@ -73,7 +73,7 @@ AC_HEADER_STDC
 AC_HEADER_DIRENT
 AC_HEADER_STAT
 AC_HEADER_TIME
-AC_CHECK_HEADERS([stdlib.h locale.h unistd.h limits.h fcntl.h string.h \
+AC_CHECK_HEADERS([stdlib.h locale.h unistd.h limits.h fcntl.h
string.h alloca.h \
   memory.h sys/param.h sys/resource.h sys/time.h sys/timeb.h \
   sys/select.h sys/file.h spawn.h])

diff --git a/lib/glob.c b/lib/glob.c
index f221a53..96783d4 100644
--- a/lib/glob.c
+++ b/lib/glob.c
@@ -30,6 +30,10 @@ USA.  */
 # define _GNU_SOURCE   1
 #endif

+#ifdef HAVE_ALLOCA_H
+# include 
+#endif
+
 #include 
 #include 
 #include 

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Failed compile on Fedora 28, x86_64

[Jeffrey Walton]

I'm working on Fedora 28, x86_64 (fully patched). I'm building 4.2.1
from the tarball.

I *thought* we are supposed to avoid alloca in 2018. I guess this is
another reason why.

--

...
gcc -DLOCALEDIR=\"/usr/local/share/locale\"
-DLIBDIR=\"/usr/local/lib64\" -DINCLUDEDIR=\"/usr/local/include\"
-DHAVE_CONFIG_H -I.  -I./glob  -I/usr/local/include -DNDEBUG  -g2 -O2
-m64 -march=native -fPIC -MT remote-stub.o -MD -MP -MF
.deps/remote-stub.Tpo -c -o remote-stub.o remote-stub.c
mv -f .deps/hash.Tpo .deps/hash.Po
mv -f .deps/remote-stub.Tpo .deps/remote-stub.Po
mv -f .deps/variable.Tpo .deps/variable.Po
mv -f .deps/read.Tpo .deps/read.Po
gcc  -g2 -O2 -m64 -march=native -fPIC -Wl,--export-dynamic
-L/usr/local/lib64 -m64 -Wl,-R,/usr/local/lib64 -Wl,--enable-new-dtags
-o make ar.o arscan.o commands.o default.o dir.o expand.o file.o
function.o getopt.o getopt1.o guile.o implicit.o job.o load.o
loadapi.o main.o misc.o posixos.o output.o read.o remake.o rule.o
signame.o strcache.o variable.o version.o vpath.o hash.o remote-stub.o
glob/libglob.a   -ldl -lpthread
glob/libglob.a(glob.o): In function `glob_in_dir':
/home/test/make-4.2.1/glob/glob.c:1367: undefined reference to `__alloca'
/home/test/make-4.2.1/glob/glob.c:1342: undefined reference to `__alloca'
/home/test/make-4.2.1/glob/glob.c:1256: undefined reference to `__alloca'
/home/test/make-4.2.1/glob/glob.c:1283: undefined reference to `__alloca'
glob/libglob.a(glob.o): In function `glob':
/home/test/make-4.2.1/glob/glob.c:581: undefined reference to `__alloca'
glob/libglob.a(glob.o):/home/test/make-4.2.1/glob/glob.c:732: more
undefined references to `__alloca' follow
collect2: error: ld returned 1 exit status
gmake[2]: *** [Makefile:656: make] Error 1
gmake[2]: Leaving directory '/home/test/make-4.2.1'
gmake[1]: *** [Makefile:798: all-recursive] Error 1
gmake[1]: Leaving directory '/home/test/make-4.2.1'
gmake: *** [Makefile:534: all] Error 2
Failed to build Make

--

Here's from the Fedora man pages. It should provide the header and
library information if a Fedora box is not handy.

ALLOCA(3)  Linux Programmer's Manual ALLOCA(3)

NAME
   alloca - allocate memory that is automatically freed

SYNOPSIS
   #include 

   void *alloca(size_t size);

DESCRIPTION
   The  alloca() function allocates size bytes of space in the stack frame
   of the caller.  This temporary space is automatically  freed  when  the
   function that called alloca() returns to its caller.

RETURN VALUE
   The  alloca()  function returns a pointer to the beginning of the allo‐
   cated space.  If the allocation causes stack overflow, program behavior
   is undefined.

ATTRIBUTES
   For   an   explanation   of   the  terms  used  in  this  section,  see
   attributes(7).

   ┌──┬───┬─┐
   │Interface │ Attribute │ Value   │
   ├──┼───┼─┤
   │alloca()  │ Thread safety │ MT-Safe │
   └──┴───┴─┘
CONFORMING TO
   This function is not in POSIX.1.

   There is evidence that the alloca()  function  appeared  in  32V,  PWB,
   PWB.2,  3BSD,  and  4BSD.  There is a man page for it in 4.3BSD.  Linux
   uses the GNU version.

NOTES
   The alloca() function is machine- and compiler-dependent.  For  certain
   applications,  its  use  can  improve efficiency compared to the use of
   malloc(3) plus free(3).  In certain cases, it can also simplify  memory
   deallocation  in  applications  that  use  longjmp(3) or siglongjmp(3).
   Otherwise, its use is discouraged.

   Because the space allocated by alloca() is allocated within  the  stack
   frame,  that  space  is  automatically  freed if the function return is
   jumped over by a call to longjmp(3) or siglongjmp(3).

   Do not attempt to free(3) space allocated by alloca()!

   Notes on the GNU version
   Normally, gcc(1) translates calls to alloca() with inlined code.   This
   is  not done when either the -ansi, -std=c89, -std=c99, or the -std=c11
   option is given and the header  is not included.   Otherwise,
   (without  an  -ansi  or -std=c* option) the glibc version of 
   includes  and that contains the lines:

   #ifdef  __GNUC__
   #define alloca(size)   __builtin_alloca (size)
   #endif

   with messy consequences if one has a private version of this function.

   The fact that the code is inlined means that it is impossible  to  take
   the address of this function, or to change its behavior by linking with
   a different library.

   The inlined code often consists of a single instruction  adjusting  the
   stack  pointer,  and does not check for stack overflow.  Thus, there is
   no NULL error return.

BUGS
   There is no error indication if the stack  frame  cannot  be  

Noisy compile on Fedora 28, x86_64

[Jeffrey Walton]

I'm working on Fedora 28, x86_64 (fully patched). I suppose the CFLAGS
of "-DNDEBUG  -g2 -O2 -m64 -march=native" are causing the warnings.

gcc -DHAVE_CONFIG_H -I. -I..   -I/usr/local/include -DNDEBUG  -g2 -O2
-m64 -march=native -fPIC -MT glob.o -MD -MP -MF .deps/glob.Tpo -c -o
glob.o glob.c
mv -f .deps/fnmatch.Tpo .deps/fnmatch.Po
glob.c: In function ‘glob’:
glob.c:581:23: warning: implicit declaration of function ‘__alloca’;
did you mean ‘alloca’? [-Wimplicit-function-declaration]
   newp = (char *) __alloca (dirlen + 1);
   ^~~~
   alloca
glob.c:581:14: warning: cast to pointer from integer of different size
[-Wint-to-pointer-cast]
   newp = (char *) __alloca (dirlen + 1);
  ^
glob.c:709:15: warning: cast to pointer from integer of different size
[-Wint-to-pointer-cast]
newp = (char *) __alloca (home_len + dirlen);
   ^
glob.c:732:15: warning: cast to pointer from integer of different size
[-Wint-to-pointer-cast]
newp = (char *) __alloca (end_name - dirname);
   ^
glob.c:783:15: warning: cast to pointer from integer of different size
[-Wint-to-pointer-cast]
newp = (char *) __alloca (home_len + rest_len + 1);
   ^
glob.c:814:11: warning: implicit declaration of function ‘__stat’; did
you mean ‘__xstat’? [-Wimplicit-function-declaration]
 : __stat (dirname, )) == 0
   ^~
   __xstat
glob.c: In function ‘glob_in_dir’:
glob.c:1256:21: warning: cast to pointer from integer of different
size [-Wint-to-pointer-cast]
char *fullname = (char *) __alloca (dirlen + 1 + patlen + 1);
 ^
glob.c:1283:12: warning: cast to pointer from integer of different
size [-Wint-to-pointer-cast]
names = (struct globlink *) __alloca (sizeof (struct globlink));
^
glob.c:1341:32: warning: cast to pointer from integer of different
size [-Wint-to-pointer-cast]
 struct globlink *new = (struct globlink *)
^
glob.c:1367:15: warning: cast to pointer from integer of different
size [-Wint-to-pointer-cast]
   names = (struct globlink *) __alloca (sizeof (struct globlink));
   ^

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make