Summary:	ASTERISK-16439: [patch] sounds/Makefile symbolic link has incorrect path with Make 3.80
Reporter:	Faris Raouf (faris1)	Labels:
Date Opened:	2010-07-26 15:41:42	Date Closed:	2010-07-26 20:42:43
Priority:	Blocker	Regression?	No
Status:	Closed/Complete	Components:	General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) sounds-Makefile.patch.txt
Description:	The fix for issue 17716 incorrectly creates a symbolic link in the sounds directory between Makefile and sounds/Makefile380 - the symbolic link should be to Makefile380 not sounds/Makefile380. As a result, the following is output when doing a make install: <some output removed for brevity> make -C sounds install make[1]: Entering directory `/root/asterisk-svn/asterisk-1.6.2/sounds' make[1]: Makefile: No such file or directory make[1]: *** No rule to make target `Makefile'.  Stop. make[1]: Leaving directory `/root/asterisk-svn/asterisk-1.6.2/sounds' make: *** [datafiles] Error 2 ****** ADDITIONAL INFORMATION ****** Partial output of ls -al in sounds directory, showing incorrect symbolic link: lrwxrwxrwx   1 root root   19 Jul 26 21:23 Makefile -> sounds/Makefile.380 -rw-r--r--   1 root root 6741 Jul 26 21:22 Makefile.380 -rw-r--r--   1 root root 6485 Jul 26 21:22 Makefile.381 I do not know is a similar issue happens when Make version 3.81 is installed. Incidentally, I object to being labelled a noob (see issue 17716 resolution) for using Make 3.80. Wouldn't Gnoob be more appropriate here since we are talking about GNU Make?
Comments:	By: Faris Raouf (faris1) 2010-07-26 15:43:05 Note: This is under Centos 4.8 (x86) with Make 3.80 (make-3/80-7.EL4) And oops -- I should have selected SVN under Asterisk version when submitting, rather than 1.6.2.10. By: Leif Madsen (lmadsen) 2010-07-26 16:58:01 I'm attempting to reproduce this now and test a patch from seanbright. By: Leif Madsen (lmadsen) 2010-07-26 17:09:35 I've reproduced this. If I then patch with what I've just uploaded (by seanbright) then I can install with 'make install' again. By: Sean Bright (seanbright) 2010-07-26 20:42:42 This has been resolved elsewhere by Qwell.  See 1.6.2 r279657, 1.8 r279658, and trunk r279659.