Summary:	ASTERISK-25586: uuid_generate_random detection failure
Reporter:	John Nemeth (jnemeth)	Labels:	patch
Date Opened:	2015-11-22 05:26:30.000-0600	Date Closed:	2018-03-13 17:55:45
Priority:	Minor	Regression?
Status:	Closed/Complete	Components:	Core/BuildSystem
Versions:	13.6.0	Frequency of Occurrence	Constant
Related Issues:
Environment:		Attachments:	( 0) uuid_configure.patch
Description:	configure.ac has the following (checked gitweb and trunk has the same): # Find required UUID support. #  * -luuid on Linux #  * -le2fs-uuid on OpenBSD #  * in libsystem on OS X AST_EXT_LIB_CHECK([LIBUUID], [uuid], [uuid_generate_random], [uuid/uuid.h], []) AST_EXT_LIB_CHECK([E2FSUUID], [e2fs-uuid], [uuid_generate_random], [uuid/uuid.h] , []) AC_CHECK_FUNCS([uuid_generate_random], [SYSUUID=true], [SYSUUID=""]) On my system (NetBSD with libuuid package installed), the first test returns "yes", and the rest return "no": checking for uuid_generate_random in -luuid... yes checking uuid/uuid.h usability... yes checking uuid/uuid.h presence... yes checking for uuid/uuid.h... yes checking for uuid_generate_random in -le2fs-uuid... no checking for uuid_generate_random... no The problem is that the result of the later tests overwrite the results of the earlier test.  Thus the final answer is "no", even though it should be "yes". I have marked this bug as "minor" because the test result isn't actually used.  This could be considered to be a seperate bug, i.e. the result should be used, or the test should be eliminated. i386devel: {1266} grep -r HAVE_UUID_GENERATE_RANDOM * configure:#define HAVE_UUID_GENERATE_RANDOM 1 include/asterisk/autoconfig.h.in:#undef HAVE_UUID_GENERATE_RANDOM include/asterisk/autoconfig.h:/* #undef HAVE_UUID_GENERATE_RANDOM */
Comments:	By: Asterisk Team (asteriskteam) 2015-11-22 05:26:31.574-0600 Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report. Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process]. By: Alexander Traud (traud) 2018-03-08 08:05:48.974-0600 The displayed output of the script {{./configure}} suggests that the final result for {{uuid_generate_random}} is 'no'. However, internally the script does something completely different: It checks three possible locations for 'uuid_generate_random'. Actually, the last output should be 'checking for uuid_generate_random *in -lsystem*... no'. Consequently, the described issue is of cosmetic nature, still horrible confusing. As you pointed out, no reason exists to do all three checks, always. When one of the previous checks succeeded, the rest should be skipped. That approach was taken in the attached patch. As a side effect it avoids that confusing configure output and therefore fixes this issue here. Or? By: Friendly Automation (friendly-automation) 2018-03-13 17:55:46.203-0500 Change 8475 merged by Jenkins2: BuildSystem: Re-check for another UUID library only when previous check failed. [https://gerrit.asterisk.org/8475|https://gerrit.asterisk.org/8475] By: Friendly Automation (friendly-automation) 2018-03-13 18:18:57.132-0500 Change 8474 merged by Jenkins2: BuildSystem: Re-check for another UUID library only when previous check failed. [https://gerrit.asterisk.org/8474|https://gerrit.asterisk.org/8474] By: Friendly Automation (friendly-automation) 2018-03-13 18:25:05.315-0500 Change 8476 merged by Joshua Colp: BuildSystem: Re-check for another UUID library only when previous check failed. [https://gerrit.asterisk.org/8476|https://gerrit.asterisk.org/8476]