(no subject)

[Thomas]

Hello,

We are currently testing ported applications to mac platform with  
some people at macports, and we having trouble with gmake port. We  
got error when running make check. Could you take a look at those  
attached files please.


Thanks for your help.

Regards.



make-3.81-check.log.bz2
Description: Binary data


make-3.81-config.log.bz2
Description: Binary data
___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: running make 3.81 tests on Mac OS X : was (no subject)

[Thomas]

That's the whole work dir :



work.tgz
Description: Binary data



Regards
Thomas

Le 21 mars 07 à 22:35, Jon Grant a écrit :


Hi Thomas,

thanks for your email. The key part of the make 3.81 testsuite log  
is this:


features/default_names .. Error
running /Users/thomas/Desktop/tmp/make-3.81/tests/../make (expected 0;
got 512): /Users/thomas/Desktop/tmp/make-3.81/tests/../make
ok (4 passed)

I don't know of a problem in this area.  Does anyone else?

Thomas: Could you send that specific diff file in the work dir to this
mailing list please? (or send the group if you cant figure out which
to send)

Regards
Jon



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

problem of Pattern Rules

[thomas]

make version: 
GNU Make version 3.79.1, by Richard Stallman and
Roland McGrath.
Built for Windows32
Copyright (C) 1988, 89, 90, 91, 92, 93, 94, 95, 96,
97, 98, 99, 2000
Free Software Foundation, Inc.

operating system:
Windows 2000 Advanced Server + SP2

type of machine:
PC, CPU: Intel celeron

command shell:
cmd.exe, included in windows 2000

problem abstract:
problems when using back slash(\) in pattern rules.

problem description:
I wanted to define a implicit rule, of which the
target pattern contained a path. because I'm in
Windows platform, I used the back slash(\) instead of
slash(/).
Like this:
begin
dir\%.out : dir\%.suffer ;command
all: file.out
end
I'm sure that the file.suffer was exist! But it didn't
work! make reported an error: "make: *** No rule to
make target `dir\%.suffer', needed by `dir%.out'. 
Stop."
When I replaced the back slash(\) to slash(/) in these
rules, make worked well.

I don't think that make handle the back slash(\) well
on windows platform, perhaps.

attachment:
config.h







__
Do You Yahoo!?
Send your FREE holiday greetings online!
http://greetings.yahoo.com

/* config.h.in.  Generated automatically from configure.in by autoheader.  */

/* Define if on AIX 3.
   System headers sometimes define this.
   We just want to avoid a redefinition error message.  */
#ifndef _ALL_SOURCE
/* #undef _ALL_SOURCE */
#endif

/* Define if using alloca.c.  */
/* #undef C_ALLOCA */

/* Define if the closedir function returns void instead of int.  */
/* #undef CLOSEDIR_VOID */

/* Define to empty if the keyword does not work.  */
/* #undef const */

/* Define to one of _getb67, GETB67, getb67 for Cray-2 and Cray-YMP systems.
   This function is required for alloca.c support on those systems.  */
/* #undef CRAY_STACKSEG_END */

/* Define for DGUX with .  */
/* #undef DGUX */

/* Define if the `getloadavg' function needs to be run setuid or setgid.  */
/* #undef GETLOADAVG_PRIVILEGED */

/* Define to `unsigned long' or `unsigned long long'
   if  doesn't define.  */
#define uintmax_t unsigned long

/* Define to `int' if  doesn't define.  */
#undef gid_t
#define gid_t int

/* Define if you have alloca, as a function or macro.  */
#undef HAVE_ALLOCA
#define HAVE_ALLOCA 1

/* Define if you have  and it should be used (not on Ultrix).  */
/* #undef HAVE_ALLOCA_H */

/* Define if you don't have vprintf but do have _doprnt.  */
/* #undef HAVE_DOPRNT */

/* Define if your system has a working fnmatch function.  */
/* #undef HAVE_FNMATCH */

/* Define if your system has its own `getloadavg' function.  */
/* #undef HAVE_GETLOADAVG */

/* Define if you have the getmntent function.  */
/* #undef HAVE_GETMNTENT */

/* Define if the `long double' type works.  */
/* #undef HAVE_LONG_DOUBLE */

/* Define if you support file names longer than 14 characters.  */
#undef HAVE_LONG_FILE_NAMES
#define HAVE_LONG_FILE_NAMES 1

/* Define if you have a working `mmap' system call.  */
/* #undef HAVE_MMAP */

/* Define if system calls automatically restart after interruption
   by a signal.  */
/* #undef HAVE_RESTARTABLE_SYSCALLS */

/* Define if your struct stat has st_blksize.  */
/* #undef HAVE_ST_BLKSIZE */

/* Define if your struct stat has st_blocks.  */
/* #undef HAVE_ST_BLOCKS */

/* Define if you have the strcoll function and it is properly defined.  */
#undef HAVE_STRCOLL
#define HAVE_STRCOLL 1

/* Define if your struct stat has st_rdev.  */
#undef HAVE_ST_RDEV
#define HAVE_ST_RDEV 1

/* Define if you have the strftime function.  */
#undef HAVE_STRFTIME
#define HAVE_STRFTIME 1

/* Define if you have  that is POSIX.1 compatible.  */
/* #undef HAVE_SYS_WAIT_H */

/* Define if your struct tm has tm_zone.  */
/* #undef HAVE_TM_ZONE */

/* Define if you don't have tm_zone but do have the external array
   tzname.  */
#undef HAVE_TZNAME
#define HAVE_TZNAME 1

/* Define if you have .  */
/* #undef HAVE_UNISTD_H */

/* Define if utime(file, NULL) sets file's timestamp to the present.  */
#undef HAVE_UTIME_NULL
#define HAVE_UTIME_NULL 1

/* Define if you have .  */
/* #undef HAVE_VFORK_H */

/* Define if you have the vprintf function.  */
#undef HAVE_VPRINTF
#define HAVE_VPRINTF 1

/* Define if you have the wait3 system call.  */
/* #undef HAVE_WAIT3 */

/* Define if on MINIX.  */
/* #undef _MINIX */

/* Define if your struct nlist has an n_un member.  */
/* #undef NLIST_NAME_UNION */

/* Define if you have .  */
/* #undef NLIST_STRUCT */

/* Define if your C compiler doesn't accept -c and -o together.  */
/* #undef NO_MINUS_C_MINUS_O */

/* Define to `int' if  doesn't define.  */
#undef pid_t
#define pid_t int

/* Define if the system does not provide POSIX.1 features except
   with this defined.  */
/* #undef _POSIX_1_SOURCE */

/* Define if you need to in order for stat and other things to work.  */
#undef _POSIX_SOURCE
#define _POSIX_SOURCE 1

/* Define as the return type of signal handlers (int or void).  */
#undef RETSIGTYPE
#define RETSIGTYPE vo

[bug #20495] debug version crashes on windows on close(-1)

[Thomas Stuefe]

URL:
  <http://savannah.gnu.org/bugs/?20495>

 Summary: debug version crashes on windows on close(-1)
 Project: make
Submitted by: tstuefe
Submitted on: Monday 07/16/2007 at 07:49
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: 3.81
Operating System: MS Windows
   Fixed Release: None

___

Details:

I build gnumake and run it on windows. When executing a command ($(shell ..),
the command executes, but afterwards make crashes because the MS debug
C-Runtime detects a close(-1) and throws an error.

When debugging, I saw that the offending close was at 
function.c:1687 
  /* Close the write side of the pipe.  */
  (void) close (pipedes[1]);

pipedes[1] is -1, pipedes[0] is a valid file handle.

A workaround at this point would be a if(pipedes[1]!=-1) close(..)

...

When debugging further, I looked at the function "windows32_openpipe". What
happens is that the child process spawns fine, but the line 1490:
pipedes[1] = _open_osfhandle((long) hChildOutWr, O_APPEND);
sets pipedes[1] to -1.

I actually don't get this coding, but maybe its me. What I don't understand
is how the stdin to the child process is supposed to work at all. Parent
hands down its own duplicated stdin to the child 
(see line 1471, "hProcess = process_init_fd(hIn, hChildOutWr, 
hErr);"
and later on tries to get an OS handle for the write end of the child's
stdout pipe (line 1490)? 
As I said, maybe I simply don't get it. Microsoft's example for
stdio-redirection looks different:

http://support.microsoft.com/kb/190351
"How to spawn console processes with redirected standard handles"

Best Regards,

Thomas Stuefe




___

Reply to this item at:

  <http://savannah.gnu.org/bugs/?20495>

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



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

Internal error w.r.t. jobserver

[Thomas Schwinge]

Hello!

Would you want me to do anything to help tracking down this issue I just
hit?  ``make: INTERNAL: Exiting with 6 jobserver tokens available; should
be 5!''  I was running ``make -j 5 -l 3 target1 target2''.

I'll leave the source and build trees alone for now.


This is GNU Make 3.81, as per Ubuntu package make, version 3.81-3build1.


Regards,
 Thomas


PS: I'm not subscribed to bug-make.


signature.asc
Description: Digital signature
___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

make 3.82 fails on powerpc defconfig update [was: Linux 2.6.35]

[Thomas Backlund]

Hi,
(please cc me as I'm not subscribed)

updating from make 3.81 to 3.82 gets me this:

[tho...@tmb linux-2.6.35]$ cp arch/powerpc/configs/ppc64_defconfig .config
[tho...@tmb linux-2.6.35]$ LC_ALL=C make oldconfig ARCH=powerpc
/mnt/work/2.6.35/linux-2.6.35/arch/powerpc/Makefile:183: *** mixed 
implicit and normal rules.  Stop.


The lines are:

182:
183: $(BOOT_TARGETS): vmlinux
184: $(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst 
%,$(boot)/%,$@)

185:

BOOT_TARGETS are defined on line 166 as:
BOOT_TARGETS = zImage zImage.initrd uImage zImage% dtbImage% treeImage.% 
cuImage.% simpleImage.%



Now it's not a regression in the kernel as the same happends with the 
2.6.34 tree too.


(btw, the host I'm syncing the defconfig with is a x86_64 machine)


Now, I dont know if this is "intended breakage" by the make update, or 
if the Makefile needs to be updated


Any ideas how to fix ?

--
Thomas


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

Re: make 3.82 fails on powerpc defconfig update [was: Linux 2.6.35]

[Thomas Backlund]

02.08.2010 21:28, Sam Ravnborg skrev:
> On Mon, Aug 02, 2010 at 11:51:11AM +0300, Thomas Backlund wrote:
>> Hi,
>> (please cc me as I'm not subscribed)
>>
>> updating from make 3.81 to 3.82 gets me this:
>>
>> [tho...@tmb linux-2.6.35]$ cp arch/powerpc/configs/ppc64_defconfig .config
>> [tho...@tmb linux-2.6.35]$ LC_ALL=C make oldconfig ARCH=powerpc
>> /mnt/work/2.6.35/linux-2.6.35/arch/powerpc/Makefile:183: *** mixed  
>> implicit and normal rules.  Stop.
>>
>> The lines are:
>>
>> 182:
>> 183: $(BOOT_TARGETS): vmlinux
>> 184: $(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst  
>> %,$(boot)/%,$@)
>> 185:
>>
>> BOOT_TARGETS are defined on line 166 as:
>> BOOT_TARGETS = zImage zImage.initrd uImage zImage% dtbImage% treeImage.%  
>> cuImage.% simpleImage.%
>>
>>
>> Now it's not a regression in the kernel as the same happends with the  
>> 2.6.34 tree too.
>>
>> (btw, the host I'm syncing the defconfig with is a x86_64 machine)
>>
>>
>> Now, I dont know if this is "intended breakage" by the make update, or  
>> if the Makefile needs to be updated
>>
>> Any ideas how to fix ?
> 
> This is in the category "intended breakage".
> We had a similar issue in the top-level Makefile which Paul (IIRC)
> helped me to fix long time ago.
> 
> To fix popwerpc I suggest something along these lines.
> [Note: I did not test it - please do so.
> 
>   Sam
> 
> [PATCH] powerpc: fix build with make 3.82
> 
> Thomas Backlund reported that the powerpc build broke with make 3.82.
> It failed with the following message:
> 
> arch/powerpc/Makefile:183: *** mixed implicit and normal rules.  Stop.
> 
> The fix is to avoid mixing non-wildcard and wildcard targets.
> 
> Reported-by: Thomas Backlund 
> Cc: Michal Marek 
> Signed-off-by: Sam Ravnborg 
> ---
> diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
> index 77cfe7a..ad88b21 100644
> --- a/arch/powerpc/Makefile
> +++ b/arch/powerpc/Makefile
> @@ -163,9 +163,11 @@ drivers-$(CONFIG_OPROFILE)   += 
> arch/powerpc/oprofile/
>  # Default to zImage, override when needed
>  all: zImage
>  
> -BOOT_TARGETS = zImage zImage.initrd uImage zImage% dtbImage% treeImage.% 
> cuImage.% simpleImage.%
> +# With make 3.82 we cannot mix normal and wildcard targets
> +BOOT_TARGETS1 := zImage zImage.initrd uImaged
> +BOOT_TARGETS2 := zImage% dtbImage% treeImage.% cuImage.% simpleImage.%
>  
> -PHONY += $(BOOT_TARGETS)
> +PHONY += $(BOOT_TARGETS1) $(BOOT_TARGETS2)
>  
>  boot := arch/$(ARCH)/boot
>  
> @@ -180,7 +182,9 @@ relocs_check: arch/powerpc/relocs_check.pl vmlinux
>  zImage: relocs_check
>  endif
>  
> -$(BOOT_TARGETS): vmlinux
> +$(BOOT_TARGETS1): vmlinux
> + $(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst %,$(boot)/%,$@)
> +$(BOOT_TARGETS2): vmlinux
>   $(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst %,$(boot)/%,$@)
>  
>  bootwrapper_install %.dtb:


Thanks, this seems to fix the first issue, but then I get the same erro on the 
following line 190:

190: bootwrapper_install %.dtb:
191:$(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst %,$(boot)/%,$@)


--
Thomas

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

Re: make 3.82 fails on powerpc defconfig update [was: Linux 2.6.35]

[Thomas Backlund]

02.08.2010 23:51, Sam Ravnborg skrev:
>>
>> Thanks, this seems to fix the first issue, but then I get the same erro on 
>> the following line 190:
>>
>> 190: bootwrapper_install %.dtb:
>> 191:$(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst 
>> %,$(boot)/%,$@)
>>
> 
> Obviously - dunno how I missed that.
> Updated patch below.
> 
> I will do a proper submission after you
> confirm that powerpc build is working with make 3.82.
> 

Yeah, that was an obvious fix, thanks!

One small typo fix below...
(a missing ':')

Otherwise it works here, so:

Tested-by: Thomas Backlund 

>   Sam
> 
> diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
> index 77cfe7a..ace7a3e 100644
> --- a/arch/powerpc/Makefile
> +++ b/arch/powerpc/Makefile
> @@ -163,9 +163,11 @@ drivers-$(CONFIG_OPROFILE)   += 
> arch/powerpc/oprofile/
>  # Default to zImage, override when needed
>  all: zImage
>  
> -BOOT_TARGETS = zImage zImage.initrd uImage zImage% dtbImage% treeImage.% 
> cuImage.% simpleImage.%
> +# With make 3.82 we cannot mix normal and wildcard targets
> +BOOT_TARGETS1 := zImage zImage.initrd uImaged
> +BOOT_TARGETS2 := zImage% dtbImage% treeImage.% cuImage.% simpleImage.%
>  
> -PHONY += $(BOOT_TARGETS)
> +PHONY += $(BOOT_TARGETS1) $(BOOT_TARGETS2)
>  
>  boot := arch/$(ARCH)/boot
>  
> @@ -180,10 +182,16 @@ relocs_check: arch/powerpc/relocs_check.pl vmlinux
>  zImage: relocs_check
>  endif
>  
> -$(BOOT_TARGETS): vmlinux
> +$(BOOT_TARGETS1): vmlinux
> + $(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst %,$(boot)/%,$@)
> +$(BOOT_TARGETS2): vmlinux
> + $(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst %,$(boot)/%,$@)
> +
> +
> +bootwrapper_install

bootwrapper_install:

>   $(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst %,$(boot)/%,$@)
>  
> -bootwrapper_install %.dtb:
> +%.dtb:
>   $(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst %,$(boot)/%,$@)
>  
>  define archhelp
> .
> 

--
Thomas

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

Fix for comment typo

[Reuben Thomas]

Below, a patch for a comment fix in variable.c. The original was
sufficiently obscure that you'll want to check my rewrite does in fact
have the correct meaning:

---cut here---
Index: variable.c
===
RCS file: /sources/make/make/variable.c,v
retrieving revision 1.108
diff -u -r1.108 variable.c
--- variable.c  18 Apr 2011 01:25:20 -      1.108
+++ variable.c  12 Jul 2011 12:21:59 -
@@ -339,8 +339,8 @@

  /* This one actually turns out to be very hard, due to the way the parser
     records targets.  The way it works is that target information is collected
-     internally until make knows the target is completely specified.  It unitl
-     it sees that some new construct (a new target or variable) is defined that
+     internally until make knows the target is completely specified.  When it
+     sees that some new construct (a new target or variable) is defined,
     it knows the previous one is done.  In short, this means that if you do
     this:

---cut here---

--
http://rrt.sc3d.org



-- 
http://rrt.sc3d.org

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

Problem with secondary expansion and target specific variables

[Thomas Daniel]

The following makefile.1 produces correct results:
---
target1 : var := one
target2 : var := two

targets := target1 target2

all : $(targets)

.SECONDEXPANSION:
$(targets) : foo/$$(var)/bar

foo/%/bar :
mkdir -p $(dir $@)
touch $@

.PHONY : target1 target2
-

> make -f makefile.1
mkdir -p foo/one/
touch foo/one/bar
mkdir -p foo/two/
touch foo/two/bar

However, makefile.2 does not pick up var:
-
target1 : var := one
target2 : var := two

targets := target1 target2

all : $(targets)

.SECONDEXPANSION:
$(targets) : test/$$@

$(targets:%=test/%) : foo/$$(var)/bar

foo/%/bar :
mkdir -p $(dir $@)
touch $@

.PHONY : $(targets) $(targets:%=test/%)


> make -f makefile.2
make: *** No rule to make target `foo//bar', needed by `test/target1'.  
Stop.


According to make documentation:
"when you define a target-specific variable that variable value is also 
in effect for all prerequisites of this target, and all their 
prerequisites, etc."


Since test/target1 is a prerequisite for target1 and var is defined for 
target1, it should be available also for test/target1. Secondary 
expansion works when expanding 'var' for target1 and target2 in 
makefile.1, but it doesn't when expanding it in makefile.2


Am I doing something incorrect here or is it an unimplemented 
functionality, specifically that target specific variables are not 
inherited in prerequisites  of prerequisite?


The behavior is the same in 3.81 and 3.82.

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

pcc fix for gmake

[Thomas Klausner]

Hi!

I've just updated the pkgsrc version of GNU make to 4.0. While doing
that I found an old patch that was added to the package for PCC
compatibility. It looks sane enough, perhaps you can integrate it?

Thanks,
 Thomas
$NetBSD: patch-pa,v 1.1 2009/10/30 18:20:04 ahoka Exp $

PCC says: hash.c:326: error: Constant "4294967295" is out of range

--- hash.c.orig 2006-02-11 21:00:39.0 +0100
+++ hash.c
@@ -323,7 +323,7 @@ round_up_2 (unsigned long n)
   n |= (n >> 8);
   n |= (n >> 16);
 
-#if !defined(HAVE_LIMITS_H) || ULONG_MAX > 4294967295
+#if !defined(HAVE_LIMITS_H) || ULONG_MAX > 4294967295ul
   /* We only need this on systems where unsigned long is >32 bits.  */
   n |= (n >> 32);
 #endif
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #48045] gmake-4.2 breaks firefox-46.0.1 build

[Thomas Klausner]

URL:
  

 Summary: gmake-4.2 breaks firefox-46.0.1 build
 Project: make
Submitted by: tk
Submitted on: Sat 28 May 2016 10:27:29 AM GMT
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: 4.2
Operating System: None
   Fixed Release: None
   Triage Status: None

___

Details:

When upgrading gmake from 4.1 to 4.2, firefox-46.0.1 does not build any
longer.

The build ends with:

../config/nsinstall -R system_wrappers ../dist
../config/nsinstall: cannot access system_wrappers: No such file or directory
make[5]: *** [Makefile:65: export] Error 1
make[5]: Leaving directory '/usr/src/firefox-46.0.1/firefox-build/config'

See https://bugzilla.mozilla.org/show_bug.cgi?id=1275547 for the firefox bug
report.

I don't know if it's a Makefile bug or a bug in GNU make.




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


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

debugging errant Makefile's

[Jim Thomas]

Aloha,

I'm trying to debug a problem of some sort in a make.  The output from
make -p is included below.  If you've seen something like the original
problem before, I'd appreciate a clue.  The actual commands lost something
between the "%: %.c" rule shown in the dump and their execution - the RM
and the first parts of the COMPILE.c and LINK.c .  Since the dump shows the
right rules, I'm inclined to think it's a make problem, but ... ?  It also
fails in 3.76.1 .

But this report is on the paths shown for the Makefile's in the dump.  You
may note that many of them are garbage.  The system this comes from (EPICS)
uses lots of include's including other include's.  I tried a bit to see if
I saw the garbage in our other makes (none of which do more than one level
of include) - one worked fine and the other didn't print any paths at all
on the "# makefile" lines  .

Below the -p output is a gzipped tar file with (I think legally) all the
files needed (I think, I tried it, but there may well be something coming
in from my environment :-( to reproduce both problems.  Untar it somewhere,
cd to uae/uae , and type make .  The right include files should be there
for hpux/solaris/linux ...

Thank you for added the path print out in the first place.  It helps a
lot.  Now if there were only a way to print out where each part of each
command that gets executed came from 

Mahalo,
Jim

make was compiled with gcc 2.7.2.3 .
=== 8< ---
# GNU Make version 3.79, by Richard Stallman and Roland McGrath.
# Built for hppa1.1-hp-hpux10.20
# Copyright (C) 1988, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99
#   Free Software Foundation, Inc.
# This is free software; see the source for copying conditions.
# There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
# PARTICULAR PURPOSE.

# Report bugs to <[EMAIL PROTECTED]>.

/usr/local/bin/perl /h/thomas/EPICS/base/bin/hp700/makeMakefile.pl O.hp700 Host
make -C O.hp700 -f ../Makefile.Host T_A=hp700 BUILD_TYPE=Host install
# GNU Make version 3.79, by Richard Stallman and Roland McGrath.
# Built for hppa1.1-hp-hpux10.20
# Copyright (C) 1988, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99
#   Free Software Foundation, Inc.
# This is free software; see the source for copying conditions.
# There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
# PARTICULAR PURPOSE.

# Report bugs to <[EMAIL PROTECTED]>.

# make[1]: Entering directory `/h/thomas/EPICS/uae/O.hp700'
EXE -macTest- from -../macTest.c-
D_HPUX_SOURCE -DHP_UX   -DUNIX  -I. -I..  -I/h/thomas/EPICS/base/include 
-I/h/thomas/EPICS/base/include/os/hp700  -c   ../macTest.c
make[1]: D_HPUX_SOURCE: Command not found
make[1]: [macTest] Error 127 (ignored)
o macTest  -D_HPUX_SOURCE -DHP_UX   -DUNIX  -I. -I..  
-I/h/thomas/EPICS/base/include -I/h/thomas/EPICS/base/include/os/hp700 
-L/h/thomas/EPICS/base/lib/hp700/ macTest.o   -lCom -lm
make[1]: o: Command not found
make[1]: [macTest] Error 127 (ignored)
end EXE
/host/parisc-hpux10/bin/mangen -s ../applSetup
make[1]: /host/parisc-hpux10/bin/mangen: Command not found
make[1]: *** [applSetup.1] Error 127

# Make data base, printed on Fri May 19 14:49:20 2000

# Variables

# makefile (from `base/config/CONFIG_SITE_HOST_ARCH.hp700', line 152)
DBST = $(EPICS_EXTENSIONS)/bin/$(HOST_ARCH)/dbst
# makefile (from `base/config/CONFIG_SITE_HOST_ARCH.hp700', line 70)
VX_GNU_NO = $(VX_DIR_NO)/../vxgccV2.2.3.1
# default
F77 = $(FC)
# environment
SHLIB_PATH = /opt/Tornado/host/parisc-hpux10/lib:/opt/Tornado/host/parisc-hpux10/lib
# makefile (from `EPICS_VERSION', line 186)
OPT_LDFLAGS = 
# makefile (from `EPICS_VERSION', line 13)
CROSS1 = $(CROSS_COMPILER_TARGET_ARCHS$(word 1,$(CROSS_COMPILER_HOST_ARCHS)))
# makefile (from `/h/thomas/EPICS/base/config/RULES.Host', line 453)
INSTALL_JAR = $(JAR:%=$(INSTALL_JAVA)/%)
# makefile (from `/h/thomas/EPICS/base/config/RULES.Host', line 369)
COND_PROD_SRCS = $(foreach prod, $(basename $(PROD)), $($(prod)_SRCS))
# makefile (from `EPICS_VERSION', line 184)
OPT_CFLAGS = $($(ANSI)_OPT_$(HOST_OPT))
# default
PREPROCESS.r = $(FC) $(FFLAGS) $(RFLAGS) $(TARGET_ARCH) -F
# makefile (from `EPICS_VERSION', line 225)
CPPSNCFLAGS = $(INCLUDES)
# makefile (from `base/config/CONFIG_SITE_HOST_ARCH.hp700', line 55)
TORNADO = YES
# makefile (from `EPICS_VERSION', line 19)
BUILD_ARCHS = $(HOST_ARCH) $(CROSS1) $(CROSS2)
# environment
CFHTCONFPATH = /cfht/conf
# environment
dtstart_sessionlogfile = /dev/null
# makefile (from `@
3€', line 45)
HPCC_SHRLIB_LDFLAGS_YES = -b
# makefile (from `/h/thomas/EPICS/base/config/RULES.Host', line 248)
INSTALL_TCLINDEX = $(TCLINDEX:%=$(INSTALL_TCLLIB)/%)
# makefile (from `@
3€', line 43)
HPCC_SLIBS_NO = 
# makefile (from `@', line 14)
EPICS_UPDATE_LEVEL = 0
# makefile (from `EP

Re: debugging errant Makefile's

[Jim Thomas]

> "Paul" == Paul D Smith <[EMAIL PROTECTED]> writes:

Paul> It seems like you've got some serious memory corruption here, but
Paul> I've never seen anything like this before.

Paul> You don't have a copy of Purify lying around anywhere, have you?
Paul> If not, the dmalloc library will do; if you have a copy you can
Paul> configure make with --enable-dmalloc and rebuild and see if that
Paul> gives you any help.

Yup, I'll run purify on it and see what I get.  I'll try to do that
tomorrow.  I was also thinking of trying HP CC on it (for grins).

Jim

Re: debugging errant Makefile's

[Jim Thomas]

> "Paul" == Paul D Smith <[EMAIL PROTECTED]> writes:

Paul> Doh.  I don't know what I was thinking.  This one is easy.  Your
Paul> rule is:

Doh is right.  Sorry to have bothered you with that part of it :-(

Mahalo,
Jim

make for windows use the incorrect date for update check

[Thomas Heidler]

Make use the creation time instead the modification time for update check.

best regards

Thomas Heidler


# GNU Make version 3.79.1, by Richard Stallman and Roland McGrath.
# Built for Windows32
# Copyright (C) 1988, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 2000
#   Free Software Foundation, Inc.
# This is free software; see the source for copying conditions.
# There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
# PARTICULAR PURPOSE.



___
Bug-make mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-make

make crash with $(shell...) under NT

[Thomas LECHEVALIER]

> Hello,

I a doing a nmake NT and Unix make porting for my company.
Unfortunately, I get a stack dump, when i call $(shell..) under NT:

> Here is the error:
> 
>   0 [main] make 262 handle_exceptions: Exception:
> STATUS_ACCESS_VIOLATION
>1361 [main] make 262 open_stackdumpfile: Dumping stack trace to
> make.exe.stackdump
> 

> Here is a makefile example:

> ===
> toto:=$(shell ls *.C)
>
> all:
> @echo $toto
> ===
> It is too bad because the same makefile works fine under unix.
>
> If you have any idea ?

I am running make 3.79.1


___
Bug-make mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-make

Error Making GDB for eCos

[Thomas Joseph]

Dear Sir

I can't make the gdb stubs as an errore occurs. Please suggest any method to make 
i386-elf-gdb from Insight or standard gbd.

I hereby attached the make.out file for your kind reference

Yours Sincerely
Thomas Joseph


make: Entering directory `/tmp/build/gdb'
make[1]: Entering directory `/tmp/build/gdb/libiberty'
if [ x"no" = xyes ] && [ ! -d pic ]; then \
  mkdir pic; \
else true; fi
touch stamp-picdir
test x"no" != xyes || \
  gcc -mwin32 -c -DHAVE_CONFIG_H -g -O2 -I. 
-I/src/gdb/insight-5.0/libiberty/../include  -W -Wall -Wtraditional  
/src/gdb/insight-5.0/libiberty/argv.c -o pic/argv.o
gcc -mwin32 -c -DHAVE_CONFIG_H -g -O2 -I. -I/src/gdb/insight-5.0/libiberty/../include  
-W -Wall -Wtraditional /src/gdb/insight-5.0/libiberty/argv.c
cc1.exe: Invalid option `win32'
make[1]: *** [argv.o] Error 1
make[1]: Leaving directory `/tmp/build/gdb/libiberty'
make: *** [all-libiberty] Error 2
make: Leaving directory `/tmp/build/gdb'


_
For Rs. 2,000,000 worth of Aptech scholarships click below
http://events.rediff.com/aptechsch/scholarship.htm




___
Bug-make mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-make

GNU Make Question

[Thomas Tan]

To whom it may concern,

Somehow, the "gnu.ps" postscript file does not have page numbered
when printed. This makes future reference to a certain page
number extremely difficult after consulting the "Index of Concepts"
index.

Is there anything that I can do ? please let me know.

Thanks,


begin:vcard 
n:Tan;Thomas
x-mozilla-html:FALSE
org:;Lockheed Martin Mission System
adr:;;
version:2.1
email;internet:[EMAIL PROTECTED]
title:Software Engineer
note:Tel:(732)450-7031
x-mozilla-cpt:;768
fn:Thomas Tan
end:vcard

[PATCH] Re: make-3.79.1 bug breakslinux-2.5.24/drivers/net/hamradio/soundmodem

[Thomas Sailer]

On Sat, 2002-06-22 at 08:57, Adam J. Richter wrote:
>   linux-2.5.24/drivers/net/hamradio/soundmodem/Makefile contains
> the following rule:
> 
> $(obj)/sm_tbl_%: $(obj)/gentbl
> $<
> 
>   obj was set to "." /usr/src/linux/Rules.make, which was included
> earlier in the Makefile.
> 
>   The problem is that when make executes this rule it executes
> "gentbl" rather than "./gentbl".  This causes the command to fail if
> you do not have "." in your path.  Make-3.79.1 is apparently being too
> clever in expanding file names.  I think this is a make bug.

Thanks for investigating this, but I propose another fix, namely to
remove soundmodem altogether. Linus, please do:

rm -rf drivers/net/hamradio/soundmodem
and then apply the attached patch.

Why?
* There is a usermode only replacement now (and for several years
already), which works with most OSS interface sound drivers
* The kernel stuff is limited to a few ISA cards, and nowadays
mainboards with ISA slots almost ceased to exist, same with ISA
soundcards

Thanks

Tom



--- linux-2.5.24/drivers/net/hamradio/Config.in.sm  Mon Jun 24 17:22:03 2002
+++ linux-2.5.24/drivers/net/hamradio/Config.in Mon Jun 24 17:22:44 2002
@@ -18,18 +18,5 @@
 dep_tristate 'BAYCOM picpar and par96 driver for AX.25' CONFIG_BAYCOM_PAR 
$CONFIG_PARPORT $CONFIG_AX25
 dep_tristate 'BAYCOM epp driver for AX.25' CONFIG_BAYCOM_EPP $CONFIG_PARPORT 
$CONFIG_AX25
 
-dep_tristate 'Soundcard modem driver' CONFIG_SOUNDMODEM $CONFIG_PARPORT $CONFIG_AX25
-if [ "$CONFIG_SOUNDMODEM" != "n" ]; then
-   bool '  soundmodem support for Soundblaster and compatible cards' 
CONFIG_SOUNDMODEM_SBC
-   bool '  soundmodem support for WSS and Crystal cards' CONFIG_SOUNDMODEM_WSS
-   bool '  soundmodem support for 1200 baud AFSK modulation' 
CONFIG_SOUNDMODEM_AFSK1200
-   bool '  soundmodem support for 2400 baud AFSK modulation (7.3728MHz crystal)' 
CONFIG_SOUNDMODEM_AFSK2400_7
-   bool '  soundmodem support for 2400 baud AFSK modulation (8MHz crystal)' 
CONFIG_SOUNDMODEM_AFSK2400_8
-   bool '  soundmodem support for 2666 baud AFSK modulation' 
CONFIG_SOUNDMODEM_AFSK2666
-   bool '  soundmodem support for 4800 baud HAPN-1 modulation' 
CONFIG_SOUNDMODEM_HAPN4800
-   bool '  soundmodem support for 4800 baud PSK modulation' CONFIG_SOUNDMODEM_PSK4800
-   bool '  soundmodem support for 9600 baud FSK G3RUH modulation' 
CONFIG_SOUNDMODEM_FSK9600
-fi
-
 dep_tristate 'YAM driver for AX.25' CONFIG_YAM $CONFIG_AX25
 
--- linux-2.5.24/drivers/net/hamradio/Makefile.sm   Mon Jun 24 17:22:07 2002
+++ linux-2.5.24/drivers/net/hamradio/Makefile  Mon Jun 24 17:22:30 2002
@@ -22,6 +22,5 @@
 obj-$(CONFIG_BAYCOM_SER_HDX)   += baycom_ser_hdx.o hdlcdrv.o
 obj-$(CONFIG_BAYCOM_PAR)   += baycom_par.o hdlcdrv.o
 obj-$(CONFIG_BAYCOM_EPP)   += baycom_epp.o hdlcdrv.o
-obj-$(CONFIG_SOUNDMODEM)   += soundmodem/  hdlcdrv.o
 
 include $(TOPDIR)/Rules.make
--- linux-2.5.24/drivers/net/hamradio/Config.help.smMon Jun 24 17:23:49 2002
+++ linux-2.5.24/drivers/net/hamradio/Config.help   Mon Jun 24 17:24:13 2002
@@ -161,87 +161,3 @@
   say M here and read .  This is
   recommended.  The module will be called baycom_ser_hdx.o.
 
-CONFIG_SOUNDMODEM
-  This experimental driver allows a standard Sound Blaster or
-  WindowsSoundSystem compatible sound card to be used as a packet
-  radio modem (NOT as a telephone modem!), to send digital traffic
-  over amateur radio.
-
-  To configure the driver, use the sethdlc, smdiag and smmixer
-  utilities available in the standard ax25 utilities package. For
-  information on how to key the transmitter, see
-   and
-  .
-
-  If you want to compile this driver as a module ( = code which can be
-  inserted in and removed from the running kernel whenever you want),
-  say M here and read .  This is
-  recommended.  The module will be called soundmodem.o.
-
-CONFIG_SOUNDMODEM_SBC
-  This option enables the soundmodem driver to use Sound Blaster and
-  compatible cards. If you have a dual mode card (i.e. a WSS cards
-  with a Sound Blaster emulation) you should say N here and Y to
-  "Sound card modem support for WSS and Crystal cards", below, because
-  this usually results in better performance. This option also
-  supports SB16/32/64 in full-duplex mode.
-
-CONFIG_SOUNDMODEM_WSS
-  This option enables the soundmodem driver to use WindowsSoundSystem
-  compatible cards. These cards feature a codec chip from either
-  Analog Devices (such as AD1848, AD1845, AD1812) or Crystal
-  Semiconductors (such as CS4248, CS423x). This option also supports
-  the WSS full-duplex operation which currently works with Crystal
-  CS423x chips. If you don't need full-duplex operation, do not enable
-  it to save performance.
-
-CONFIG_SOUNDMODEM_AFSK1200
-  This option enables the soundmodem driver 1200 baud AFSK modem,
-  compatible to popular modems using TCM3105 or AM7911. The
-  demodulator requires a

incompatibility with unix make

[Thomas Abendroth]

Hi,

I use GNU-make WIN32 version 3.79.1. for some days and I found out, that the
makefile code below does not work.
With Borland 'make' and Solaris 'make' the same makefile works perfectly.

best regards
Thomas

#--- my simplified makefile -#

ObjectDir = ./objects

#- compiler settings -#

UnixCompiler = cc
Msvc98Compiler = cl

UnixCflags = -c -Kpic -g -temp=/tmp
Msvc98Cflags = /nologo /MDd /W3 /Gm /GX /ZI /Od /D "WIN32" /c

UnixIncludePath = -I. -I../include
Msvc98IncludePath = /I "D:\Programme\Microsoft Visual Studio\VC98\include"
/I. /I../include

UnixObjExt = o
Win32ObjExt = obj

UnixObjName = -o $@
Msvc98ObjName = /Fo$@

UnixRemove = rm -f
Win32Remove = del

#I don't know any method for automatical setting on WIN32, so have to do it
manually

CC = $(Msvc98Compiler)
CFLAGS = $(MSvc98Cflags)
INCLUDE_PATH = $(Msvc98IncludePath)
OBJECT_NAME = $(Msvc98ObjName)
OBJ = $(Win32ObjExt)
RM = $(Win32Remove)

#- output #

Output = \
$(ObjectDir)/mySourceFile.$(OBJ) \
$(ObjectDir)/... \
$(ObjectDir)/... \
etc.

# make ---#

all: $(Output)
@echo "make finished"

clean:
$(RM) $(Output)

#--- compilation --#

.SUFFIXES: .$(OBJ).cpp

.cpp.$(OBJ):
@echo " "
@echo Compiling $<
$(CC) $(CFLAGS) $(INCLUDE_PATH) $< $(OBJECT_NAME)

#- dependencies -#

$(ObjectDir)/mySourceFile.$(OBJ): mySourceFile.cpp myHeaderFile.h

$(ObjectDir)/...

$(ObjectDir)/...

etc.

#--- end of makefile #




___
Bug-make mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-make

[bug #15818] SEGV in hash set code

[Thomas Bleher]

Follow-up Comment #1, bug #15818 (project make):

Not sure if this is the same bug, but the backtraces seem similar.
I use make CVS as of today (2006-02-21), Ubuntu Dapper (development version
of Ubuntu).

I'm trying to build SELinux refpolicy, my current source is available as
http://www.cip.ifi.lmu.de/~bleher/refpolicy-segfault.tar.gz.
Whenever I call "make -C build-tree/refpolicy NAME=refpolicy-strict
TYPE=strict-mcs DISTRO=debian DIRECT_INITRC=y MONOLITHIC=n all" on this exact
tree make immediately segfaults.

Backtrace from gdb:
(gdb) backtrace
#0  0x080628c4 in merge_variable_set_lists (setlist0=0x809fcfc,
setlist1=0x80bd2c0) at variable.c:682
#1  0x0804d7f4 in rehash_file (from_file=0x80ab9b8, to_hname=0x80bd770
"policy/modules/kernel/corenetwork.te")
at file.c:298
#2  0x0805e932 in f_mtime (file=, search=1) at
remake.c:1247
#3  0x0805f3ec in check_dep (file=, depth=8,
this_mtime=1, must_make_ptr=0x3f8424d4)
at remake.c:971
#4  0x0805f2e3 in check_dep (file=0x80a0388, depth=7, this_mtime=1,
must_make_ptr=0x3f842524) at remake.c:1009
#5  0x0805f2e3 in check_dep (file=0x8096e70, depth=6, this_mtime=1,
must_make_ptr=0x3f842574) at remake.c:1009
#6  0x0805f2e3 in check_dep (file=0x809f660, depth=5, this_mtime=1,
must_make_ptr=0x3f8425c4) at remake.c:1009
#7  0x0805f2e3 in check_dep (file=0x809f550, depth=4, this_mtime=1,
must_make_ptr=0x3f842654) at remake.c:1009
#8  0x0805f7ab in update_file (file=0x80963e0, depth=2) at remake.c:504
#9  0x0805f126 in check_dep (file=, depth=2,
this_mtime=1, must_make_ptr=0x3f842734)
at remake.c:941
#10 0x0805f7ab in update_file (file=0x8071660, depth=0) at remake.c:504
#11 0x080609be in update_goal_chain (goals=0x80984d0) at remake.c:154
#12 0x08058646 in main (argc=9, argv=0x3f8441b4, envp=0x3f8441dc) at
main.c:2200

I hope this is helpful.

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



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

[bug #15818] SEGV in hash set code

[Thomas Bleher]

Follow-up Comment #3, bug #15818 (project make):

Yes, the patch indeed fixes the problem.
Thanks for the fast reply!
Another problem appeared, but I will report this in another bug.

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



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

[bug #13529] Incorrect circular dependancy

[Thomas Bleher]

Follow-up Comment #2, bug #13529 (project make):

I'm having a similar problem (make from CVS 2006-02-21, Ubuntu Dapper):

Testcase: http://www.cip.ifi.lmu.de/~bleher/refpolicy-segfault.tar.gz (same
as in bug #15818).

When make is called on this tree with "make -C build-tree/refpolicy
NAME=refpolicy-strict TYPE=strict-mcs DISTRO=debian DIRECT_INITRC=y
MONOLITHIC=n clean all"
it complains:
"make: Circular tmp/all_te_files.conf <- corenetwork.te dependency dropped."
(sixth line of the output). The compilation continues but produces incorrect
results.
The Makefile works with earlier versions of make (unfortunately I can't say
which version exactly at the moment)

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



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

[bug #13529] Incorrect circular dependancy

[Thomas Bleher]

Follow-up Comment #3, bug #13529 (project make):

OK, I tracked down my problem and reduced it to a small testcase:

The Makefile looks like this:
vpath %.te test/
.SECONDARY:
default: test/a test/b
test/a: fail.te
test/b : fail.te
test/fail.te:

test/ exists but is empty. When I run make with this makefile it complains:
"make: Circular test/b <- fail.te dependency dropped."
This seems like a bad interaction between vpath and .SECONDARY, if I remove
one of the two lines the problem goes away.

I don't know if this is fixable, but at least a nicer error message would be
very helpful.

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



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

phony fails when the target is a recipe

[Thomas Lynch]

We have had a lot of problems with phony hints being ignored and makefiles
not running.

I've narrowed it down to a small example.  See the transcript below in this
email, or the code at
https://github.com/Reasoning-Technology/subu/tree/master/try/phony_general_targets_fail

In this example there is a target, 'lib', and there happens to be a
directory with the same name - this is a common combination.   There is a
phony declaration for lib, but it gets ignored.

I've added a second phony target, 'version', which also has a directory.
 That works.  The only difference is that the target is not given as a
pattern.  I've also run this example with a target that does not correspond
to a file or directory, and that also works as expected.

So it appears that phony hints are ignored if targets are patterns rather
than literals.  Consequently it appear that there is no way to give phony
hints in fancy makefiles that use general recipes.

Seems the phony hints should be checked against the target provided to
make, which will be literal, and then prevent the directory search.
Apparently this is not the case.  If it is only to be checked when there is
a match to a provided target, then that check would hopefully occur after
the pattern expansion.  It isn't clear to me where else it is possible to
do the check, but somehow it is doing the check somewhere else.

>

2019-04-02T10:48:22Z
user@host§~/subu_land/subu/try/phony_general_targets§
> cat makefile


.PHONY: lib version

version:
@echo "version 0.1"

%::
@echo $@



2019-04-02T10:48:27Z
user@host§~/subu_land/subu/try/phony_general_targets§
> mkdir version lib

2019-04-02T10:48:38Z
user@host§~/subu_land/subu/try/phony_general_targets§
> ls
lib  makefile  version

2019-04-02T10:48:42Z
user@host§~/subu_land/subu/try/phony_general_targets§
> make version
version 0.1

2019-04-02T10:48:50Z
user@host§~/subu_land/subu/try/phony_general_targets§
> make code
code

2019-04-02T10:48:57Z
user@host§~/subu_land/subu/try/phony_general_targets§
> make lib
make: Nothing to be done for 'lib'.

2019-04-02T10:49:00Z
user@host§~/subu_land/subu/try/phony_general_targets§
>
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: phony fails when the target is a recipe

[Thomas Lynch]

p.s.

GNU Make 4.2.1
Built for x86_64-redhat-linux-gnu
Copyright (C) 1988-2016 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.


On Tue, Apr 2, 2019 at 1:11 PM Thomas Lynch <
thomas.ly...@reasoningtechnology.com> wrote:

> We have had a lot of problems with phony hints being ignored and makefiles
> not running.
>
> I've narrowed it down to a small example.  See the transcript below in
> this email, or the code at
>
> https://github.com/Reasoning-Technology/subu/tree/master/try/phony_general_targets_fail
>
> In this example there is a target, 'lib', and there happens to be a
> directory with the same name - this is a common combination.   There is a
> phony declaration for lib, but it gets ignored.
>
> I've added a second phony target, 'version', which also has a directory.
>  That works.  The only difference is that the target is not given as a
> pattern.  I've also run this example with a target that does not
> correspond to a file or directory, and that also works as expected.
>
> So it appears that phony hints are ignored if targets are patterns rather
> than literals.  Consequently it appear that there is no way to give phony
> hints in fancy makefiles that use general recipes.
>
> Seems the phony hints should be checked against the target provided to
> make, which will be literal, and then prevent the directory search.
> Apparently this is not the case.  If it is only to be checked when there is
> a match to a provided target, then that check would hopefully occur after
> the pattern expansion.  It isn't clear to me where else it is possible to
> do the check, but somehow it is doing the check somewhere else.
>
> >
>
> 2019-04-02T10:48:22Z
> user@host§~/subu_land/subu/try/phony_general_targets§
> > cat makefile
>
>
> .PHONY: lib version
>
> version:
> @echo "version 0.1"
>
> %::
> @echo $@
>
>
>
> 2019-04-02T10:48:27Z
> user@host§~/subu_land/subu/try/phony_general_targets§
> > mkdir version lib
>
> 2019-04-02T10:48:38Z
> user@host§~/subu_land/subu/try/phony_general_targets§
> > ls
> lib  makefile  version
>
> 2019-04-02T10:48:42Z
> user@host§~/subu_land/subu/try/phony_general_targets§
> > make version
> version 0.1
>
> 2019-04-02T10:48:50Z
> user@host§~/subu_land/subu/try/phony_general_targets§
> > make code
> code
>
> 2019-04-02T10:48:57Z
> user@host§~/subu_land/subu/try/phony_general_targets§
> > make lib
> make: Nothing to be done for 'lib'.
>
> 2019-04-02T10:49:00Z
> user@host§~/subu_land/subu/try/phony_general_targets§
> >
>
>
>
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #59093] Segmentation fault regression in make 4.3 vs. 4.2.1

[Thomas Petazzoni]

URL:
  

 Summary: Segmentation fault regression in make 4.3 vs. 4.2.1
 Project: make
Submitted by: tpetazzoni
Submitted on: Thu 10 Sep 2020 03:35:12 PM UTC
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: None
Operating System: None
   Fixed Release: None
   Triage Status: None

___

Details:

GNU Make has a segmentation fault regression in make 4.3, where the exact same
make code works fine with make 4.2.1.

The stack trace looks like this:

Program received signal SIGSEGV, Segmentation fault.
0x55e0fca8530d in func_filter_filterout (o=0x55e10693b400 "",
argv=, funcname=)
at ../../src/function.c:1014
1014../../src/function.c: No such file or directory.
(gdb) 
(gdb) bt
#0  0x55e0fca8530d in func_filter_filterout (o=0x55e10693b400 "",
argv=, funcname=)
at ../../src/function.c:1014
#1  0x55e0fca86261 in handle_function (op=op@entry=0x7fff1e9c2e70,
stringp=stringp@entry=0x7fff1e9c2e68)
at ../../src/function.c:2544
#2  0x55e0fca7fe2f in variable_expand_string (line=,
line@entry=0x0, string=, 
length=length@entry=18446744073709551615) at ../../src/expand.c:258
#3  0x55e0fca7fc16 in variable_expand (line=) at
../../src/expand.c:566
#4  variable_expand_for_file (file=0x0, line=) at
../../src/expand.c:464
#5  variable_expand_for_file (file=0x0, line=) at
../../src/expand.c:457
#6  allocated_variable_expand_for_file (file=0x0, line=) at
../../src/expand.c:566
#7  expand_argument (str=0x55e106978b98 "$(filter $(VARS),$(.VARIABLES)))",
end=end@entry=0x55e106978bb7 ")")
at ../../src/expand.c:446
#8  0x55e0fca8639c in handle_function (op=op@entry=0x7fff1e9c3040,
stringp=stringp@entry=0x7fff1e9c3038)
at ../../src/function.c:2512
#9  0x55e0fca7fe2f in variable_expand_string (line=,
line@entry=0x0, 
string=string@entry=0x55e1069cfbb2 " $(sort $(filter
$(VARS),$(.VARIABLES)))", 
length=length@entry=18446744073709551615) at ../../src/expand.c:258
#10 0x55e0fca7fc7a in variable_expand (line=0x55e1069cfbb2 " $(sort
$(filter $(VARS),$(.VARIABLES)))")
at ../../src/expand.c:566
#11 variable_expand_for_file (file=0x0, line=0x55e1069cfbb2 " $(sort $(filter
$(VARS),$(.VARIABLES)))")
at ../../src/expand.c:464
#12 variable_expand_for_file (file=0x0, line=0x55e1069cfbb2 " $(sort $(filter
$(VARS),$(.VARIABLES)))")
at ../../src/expand.c:457
#13 allocated_variable_expand_for_file (file=0x0, line=0x55e1069cfbb2 " $(sort
$(filter $(VARS),$(.VARIABLES)))")
at ../../src/expand.c:566
#14 expand_argument (str=0x55e1069cfbb2 " $(sort $(filter
$(VARS),$(.VARIABLES)))", end=end@entry=0x0)
at ../../src/expand.c:436
#15 0x55e0fca83fb1 in func_foreach (o=0x55e10693a830 "",
argv=0x7fff1e9c3150, funcname=)
at ../../src/function.c:868
#16 0x55e0fca86261 in handle_function (op=op@entry=0x7fff1e9c32c0,
stringp=stringp@entry=0x7fff1e9c32b8)
at ../../src/function.c:2544
#17 0x55e0fca7fe2f in variable_expand_string (line=,
line@entry=0x0, string=, 
length=length@entry=18446744073709551615) at ../../src/expand.c:258
#18 0x55e0fca80792 in variable_expand (line=) at
../../src/expand.c:475
#19 variable_expand_for_file (line=, file=) at
../../src/expand.c:475
#20 0x55e0fca807f4 in allocated_variable_expand_for_file (line=, file=file@entry=0x55e0fe9d4280)
at ../../src/expand.c:566
#21 0x55e0fca8bc75 in new_job (file=0x55e0fe9d4280) at
../../src/job.c:1808
#22 0x55e0fca9746c in remake_file (file=0x55e0fe9d4280) at
../../src/remake.c:1234
#23 update_file_1 (depth=, file=0x55e0fe9d4280) at
../../src/remake.c:835
#24 update_file (file=file@entry=0x55e0fe9d4280, depth=) at
../../src/remake.c:336
#25 0x55e0fca97dc4 in update_goal_chain (goaldeps=) at
../../src/remake.c:151
#26 0x55e0fca7bf25 in main (argc=, argv=,
envp=)
at ../../src/main.c:2589

To reproduce:

$ git clone https://github.com/buildroot/buildroot.git
$ cd buildroot
$ make BR2_HAVE_DOT_CONFIG=y -s printvars VARS=%_LICENSE

Works with make 4.2.1 (and produces the expected output), segfaults with make
4.3 (with the above stack trace captured using gdb).




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #59093] Segmentation fault regression in make 4.3 vs. 4.2.1

[Thomas Petazzoni]

Follow-up Comment #6, bug #59093 (project make):

Any news about this bug ?

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #52922] -Otarget does not function properly and errors on FreeBSD, with stdout to a pipe

[Thomas Munro]

Follow-up Comment #3, bug #52922 (project make):

Here's a draft patch to create a lock file if an initial test of the output
descriptor fails.  Tested on FreeBSD.

I don't currently have any good ideas for how to detect redirection and use a
separate lock file.


(file #51900)
___

Additional Item Attachment:

File name: 0001-Fix-O-portability.patch   Size:4 KB
   




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #52922] -Otarget does not function properly and errors on FreeBSD, with stdout to a pipe

[Thomas Munro]

Follow-up Comment #8, bug #52922 (project make):

Yeah, it's implemented at VFS level, so it needs a vnode:

https://github.com/freebsd/freebsd-src/blob/7326e8589cc21431d62f25802eac7c5dd6f74122/sys/kern/kern_descrip.c#L617

I considered fixing that in FreeBSD, but I'm running build farm stuff across a
bunch of OSes that all have this problem hence desire to fix it here.

I haven't look at that other patch yet (at a quick glimpse I'm confused about
why it's testing every time, but I probably need to actually try it out to
have a useful opinion), but I'll be very happy however this gets fixed!

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #52922] -Otarget does not function properly and errors on FreeBSD, with stdout to a pipe

[Thomas Munro]

Follow-up Comment #11, bug #52922 (project make):

[comment #10 comment #10:]
> Is there a number of ports which have gnu make specific makefiles?

Yes.  Depending how you count there's about ~30k ports and about ~4k of them
have a build-time dependency on GNU make (I searched the FreeBSD ports tree
for "USES=.*gmake").

I'm not a ports maintainer though, I work on PostgreSQL which brought me here.
 It happens to use GNU makefiles (BSD make definitely doesn't like them), and
gets built and tested after every commit on about 10 operating systems:
https://buildfarm.postgresql.org/cgi-bin/show_status.pl

Before patches reach that stage, developer machines and CI systems also run on
several operating systems including Macs and FreeBSD, and it'd be nice to be
able to use eg make check-world -jN -Otarget to speed things up without
garbling the output.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #59093] Segmentation fault regression in make 4.3 vs. 4.2.1

[Thomas Petazzoni]

Follow-up Comment #10, bug #59093 (project make):

This bug has been fixed more than one year ago. Would it be possible to
publish a new release of GNU Make that contains this fix? Even if it's a make
4.3.1 minor release, for example. Thanks!


___

Reply to this item at:

  

___
  Message posté via Savannah
  https://savannah.gnu.org/

[bug #63737] Add --fail-on-undefined-variables

[Thomas Güttler]

URL:
  <https://savannah.gnu.org/bugs/?63737>

 Summary: Add --fail-on-undefined-variables
 Project: make
   Submitter: guettli
   Submitted: Wed 01 Feb 2023 02:49:27 PM UTC
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: None
Operating System: None
   Fixed Release: None
   Triage Status: None


___

Follow-up Comments:


---
Date: Wed 01 Feb 2023 02:49:27 PM UTC By: Thomas Güttler 
I now `--warn-undefined-variables`, but warnings get easily overlooked.

I want to be sure that no undefined variables get used in my makefile.

Why not implement a `--fail-on-undefined-variables`?

Related:
https://stackoverflow.com/questions/75311765/let-make-fail-if-makefile-encounters-undefined-variable







___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?63737>

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #63737] Add --fail-on-undefined-variables

[Thomas Güttler]

Follow-up Comment #2, bug #63737 (project make):

Thank you for comment.

Making all warnings a failure, is even better.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #63686] implement a flag to promote make warnings to fatal errors

[Thomas Güttler]

Follow-up Comment #2, bug #63686 (project make):

[comment #0 original submission:]
> GCC has a -Werror option causing warnings to be promoted to fatal errors
which I (and my organization) find very useful. As a matter of policy we
always build with -Werror on and while this, obviously, is painful to start
with it leads to a much calmer working environment once cruising altitude is
reached. We find new issues much quicker since new warnings aren't
interspersed with hundreds of pre-existing ones.


Same here. Every automated way to get better quality help us in the long run.

It would help us if we could promote warnings to fatal errors.

For example:

> Makefile:118: Warnung: undefinierte Variable „FOO“




___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #52273] Documentation about remaking makefiles should mention MAKE_RESTARTS

[Thomas ten Cate]

URL:
  

 Summary: Documentation about remaking makefiles should
mention MAKE_RESTARTS
 Project: make
Submitted by: thomastc
Submitted on: Tue 24 Oct 2017 09:29:58 AM UTC
Severity: 3 - Normal
  Item Group: Documentation
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: 4.2.1
Operating System: Any
   Fixed Release: None
   Triage Status: None

___

Details:

To resolve the confusion on https://stackoverflow.com/q/46906127/14637, hereby
a small documentation change suggestion.

I'm imagining to add a sentence to
https://www.gnu.org/software/make/manual/html_node/Remaking-Makefiles.html
along the lines of:

... make starts with a clean slate and reads all the makefiles over again. (It
will also attempt to update each of them over again, but normally this will
not change them again, since they are already up to date.) [BEGIN ADDED]During
this second run, MAKE_RESTARTS will be set to 1 (see Special Variables).[END
ADDED]




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


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