Summary:	ASTERISK-18062: menuselect dependency resolution is broken with gcc 4.6
Reporter:	mjc (mjc)	Labels:
Date Opened:	2011-06-24 09:05:54	Date Closed:	2011-07-06 13:53:41
Priority:	Major	Regression?
Status:	Closed/Complete	Components:	Core/BuildSystem
Versions:	1.6.2.16 1.6.2.18 1.8.4	Frequency of Occurrence	Constant
Related Issues:
Environment:	Fedora 15, gcc-4.6.0-9.fc15.x86_64	Attachments:	( 0) 20110702__issue18062__asterisk_trunk.diff.txt ( 1) 20110702__issue18062__menuselect.diff ( 2) 20110705__menuselect.diff.txt ( 3) patch_rej.tar
Description:	If I run "make menuselect" on Fedora 15 (gcc 4.6.0), and select "chan_dahdi", it shows: Depends on: res_smdi(M), dahdi(E), tonezone(E), pri(E), ss7(E), openr2(E) Can use: N/A This isn't right - pri, ss7, openr2 should be in the "Can use" category. This makes it a pain to install Asterisk on Fedora 15, especially since openr2 is not packaged in a convenient way (no rpm). The correct dependencies were shown in Fedora 14. I tested on 1.8.4, 1.6.2.18, 1.6.2.16. Based on the comments here, I believe this is a gcc 4.6 issue: http://forums.asterisk.org/viewtopic.php?p=158792 Also reported here: http://lists.digium.com/pipermail/asterisk-users/2011-April/261176.html - Mike
Comments:	By: Russ Meyerriecks (rmeyerriecks) 2011-06-24 15:26:03.074-0500 I have this problem, also, on my gcc version 4.6.1 box. (debian-unstable) By: Russ Meyerriecks (rmeyerriecks) 2011-06-27 15:50:41.959-0500 This can be worked around by building asterisk, deleting all references to "chan_dahdi" in menuselect.makeopts, then rebuilding. By: iasgoscouk (iasgoscouk) 2011-06-27 15:55:11.148-0500 I have already tried that - and doesn't work for me ! why do workarounds - the problem should be fixed not fudged ian By: Tzafrir Cohen (tzafrir) 2011-07-01 09:58:06.070-0500 What did autoconf report to menuselect? egrep 'DAHDI|PRI|OPENR2' build_tools/menuselect-deps By: Tilghman Lesher (tilghman) 2011-07-01 10:06:04.530-0500 The specific issue within menuselect is that configure did not detect support for either attribute weakref or attribute weak_import.  Without these methods of linking, conditional dependencies are transformed into mandatory dependencies. By: Russell Bryant (russell) 2011-07-02 06:01:47.952-0500 Thanks, Tilghman.  What's happening makes sense.  I'm not sure why those attributes aren't supported (or just not being detected), but that's another issue ... I think what should be done here is that this behavior that Tilghman describes should be modified such that this transformation _only_ happens for dependencies between Asterisk modules, not for optional dependencies on libraries.  These attributes are only relevant for how we handle APIs between Asterisk modules. By: Tilghman Lesher (tilghman) 2011-07-02 09:38:01.995-0500 Patch uploaded that adds an attribute "type" to the <use> element, with two possible values: "external" and "module".  Patch to Asterisk simply adds the new attribute to the "use" specified within the modules. By: iasgoscouk (iasgoscouk) 2011-07-02 10:26:14.024-0500 I have applied patches to the latest svn trun  on my fedora 14->15 upgrade which originally found the problem/issue. after the configure, the menuselect was already showing [*] against chan_dahdi as before. completed the make, and make install, and started asterisk and chan_dahdi loaded OK. Made outgoing and incoming calls, and working ok.   So looks ok for  me - thanks Ian By: iasgoscouk (iasgoscouk) 2011-07-03 14:19:10.609-0500 After applying the patches, as my previous post, to my fedora 14 to fedora 15 upgrade disk, I have since then built a new clean install of fedora 15 onto a new disk, and installed dahdi(2.4.1.2)/asterisk (latest SVN). Asterisk built/compiled successfully, using the patches. Now running on that server build at fedora 15 disk instead of the fedora 14 disk I had to built when the 14->15 disk failed. Ian By: Tilghman Lesher (tilghman) 2011-07-05 17:13:04.002-0500 Committed to branch 1.8, revision 326411. By: Tilghman Lesher (tilghman) 2011-07-05 21:06:43.768-0500 kpfleming mentioned he was uneasy about adding an attribute to the <use> tag, so here is another approach that simplifies menuselect's internals and allows uses to be transitioned to depends without needing to set use tag attributes. By: iasgoscouk (iasgoscouk) 2011-07-06 02:02:07.446-0500 As the previous 2 patches have been to submitted to SVN, and my tests were again SVN, does the menuselect patch need to be :  a) applied to a clean version, without the other asterisk patches, and the new menuselect patch  b) applied to a clean version, with the other asterisk patches and the new menuselect patch  c) on top of the previous 2 patches Sorry to ask, but assuming would be (c) but wanted to be sure I got it right. thanks - Ian By: Tilghman Lesher (tilghman) 2011-07-06 07:39:51.256-0500 Since the previous two patches have already been applied to SVN, it needs to be (a).  Note that it applies to the menuselect subdirectory, not the main asterisk directory. By: iasgoscouk (iasgoscouk) 2011-07-06 10:04:57.373-0500 Took latest SVN revision : 326469. Applied patch in menuselect directory, and the following messages appeared;   choose not to reverse ( as default [n]) and to apply changes.     patching file menuselect_newt.c Hunk #1 FAILED at 91. Hunk #2 FAILED at 119. 2 out of 2 hunks FAILED -- saving rejects to file menuselect_newt.c.rej patching file menuselect.c Hunk #1 FAILED at 192. Hunk #2 FAILED at 211. Hunk #3 FAILED at 345. Hunk #4 FAILED at 497. Hunk #5 FAILED at 668. Hunk #6 succeeded at 1475 with fuzz 1 (offset 776 lines). Hunk #7 FAILED at 728. Hunk #8 succeeded at 1535 with fuzz 2 (offset 788 lines). Hunk #9 FAILED at 1071. Hunk #10 FAILED at 1157. Hunk #11 FAILED at 1293. Hunk #12 FAILED at 1321. Hunk #13 FAILED at 1413. 11 out of 13 hunks FAILED -- saving rejects to file menuselect.c.rej patching file menuselect_gtk.c Hunk #1 FAILED at 269. 1 out of 1 hunk FAILED -- saving rejects to file menuselect_gtk.c.rej patching file menuselect.h Hunk #1 FAILED at 41. Hunk #2 FAILED at 106. 2 out of 2 hunks FAILED -- saving rejects to file menuselect.h.rej patching file menuselect_curses.c Hunk #1 FAILED at 183. 1 out of 1 hunk FAILED -- saving rejects to file menuselect_curses.c.rej patching file linkedlists.h Reversed (or previously applied) patch detected!  Assume -R? [n] Apply anyway? [n] y Hunk #1 FAILED at 222. 1 out of 1 hunk FAILED -- saving rejects to file linkedlists.h.rej However, I completed the 'configure' and 'make menuselect', and chan_dahdi was marked [*].  Completed make & make install and restart asterisk.  Made test calls with dahdi, and all ok Uploaded tar with 'rej' files from menuselect directory. Ian By: iasgoscouk (iasgoscouk) 2011-07-06 10:07:05.189-0500 rej files from patch on 20110705__menuselect.diff.txt By: Tilghman Lesher (tilghman) 2011-07-06 11:13:23.590-0500 You're too late.  The patch has already been applied to SVN, with one tiny change:  struct depend is now struct reference.  This issue can now be closed. By: iasgoscouk (iasgoscouk) 2011-07-06 12:26:06.185-0500 thanks for your update = i hadn't seen a further svn for the latter change otherwise wouldn't have replied. I find your 'too late' comment rather abrupt and unnecessary =  i would have thought with the amount of outstanding tasks that asterisk has, that you would have been gratefull for anyone willing to test your changes.    There is still another outstanding issue that's not resolved causing me problems, 'mixmonitor of of sync errors' which has been unprogressed, and lots or reporters have the same problem too. I'm only a reported too = this is the last time i waste my time trying to help By: Tilghman Lesher (tilghman) 2011-07-06 13:57:43.548-0500 By 'too late', I meant that you updated SVN after the fix had already been applied, which is why your patch attempt failed.  You still get the benefit of the fix, and I've explicitly mentioned you in the commit, as being someone who helpfully tested against Fedora.  You will probably see your nickname listed in the ChangeLog when 1.8.6 is released.