Noisy compile on Fedora 28, x86_64

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

Autotools requirements are too recent

$ 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

Re: Noisy compile on Fedora 28, x86_64

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 > >

Failed compile on Fedora 28, x86_64

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\"

Re: Idea: Automatically correct timestamps

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

Re: Memory leaks in Make

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

Memory leaks in Make

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

__alloca patch?

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

Re: __alloca patch?

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/msg

Re: __alloca patch?

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 &

Re: __alloca patch?

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. > &g

No rule to make ?

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 =

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

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

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

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 >

Help wanted from 2003

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

Re: Keeping intermediate files

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

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

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

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

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

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

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

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

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

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

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'

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

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

Re: [doc] MAKEOVERRIDES is undocumented

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 &

Re: [doc] MAKEOVERRIDES is undocumented

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_INC

Re: [doc] MAKEOVERRIDES is undocumented

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,

Re: GNU/Hurd installation

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

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

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

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

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

Re: [PATCH] Bad timestamps on MinGW32

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 >

Re: CentOS Stream installation

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

Re: GNU make troubleshooting

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

Re: GNU make troubleshooting

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 >

Re: GNU make troubleshooting

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),)

Re: MAKEFLAGS=-r

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

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

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