| Summary: | ASTERISK-26909: Libdir defaults to /usr/lib64 on systems that have a stray lib64 directory | ||||
| Reporter: | Walter Doekes (wdoekes) | Labels: | |||
| Date Opened: | 2017-03-30 02:18:10 | Date Closed: | 2017-04-03 07:16:31 | ||
| Priority: | Major | Regression? | Yes | ||
| Status: | Closed/Complete | Components: | Core/BuildSystem | ||
| Versions: | 13.15.0 | Frequency of Occurrence | |||
| Related Issues: |
| ||||
| Environment: | Attachments: | ||||
| Description: | For ASTERISK-26705, commit bee55aaf2cc2936100b16f5a4acb87a3ea1235cd (branch 13) added this:
{noformat} * Fedora has a /usr/share/config.site that automatically tells autoconf to use /usr/lib64 but CentOS does not. This logic was copied to configure.ac and modified so systems like Ubuntu, which still use /usr/lib for 64-bit systems, aren't affected. {noformat} {noformat} # # The following code for detecting lib64 was taken from Fedora's # /usr/share/config.site with a modification to check that the # /usr/lib64 directory actually exists. This prevents libdir from # being set to /usr/lib64 on 64-bit systems that still use /usr/lib. # if test "$prefix" = /usr ||\ { test "$prefix" = NONE && test "$ac_default_prefix" = /usr ; } then for i in x86_64 ppc64 s390x aarch64; do if test $host_cpu = $i; then if test "$libdir" = '${exec_prefix}/lib' &&\ { test -d "${exec_prefix}/lib64" || test -d "${ac_default_prefix}/lib64" ; } ; then libdir='${exec_prefix}/lib64' AC_MSG_NOTICE([ Setting libdir=${libdir} ]) fi break fi done fi {noformat} The comment is not entirely correct. Debian and Ubuntu are not systems that "still use /usr/lib", they're systems using a different schema ("multiarch" and /usr/lib/x86_64-linux-gnu, but not /usr/lib64). However, if some installer at one point has created a /usr/lib64 directory on this system (I blame opensips), the asterisk libraries will also get placed into that wrong directory. The matters get worse if you create a debian package on a build OS that accidentally has a lib64 dir: now the binary archive package introduces libraries in /usr/lib64 onto other machines, propagating the existence of the lib64 directory that's not supposed to exist. I propose to change the check from merely checking the existence, to checking for libc.so.*. For example: {noformat} # head -n4 /etc/os-release NAME="CentOS Linux" VERSION="7 (Core)" ID="centos" ID_LIKE="rhel fedora" # if [ -e /usr/lib64/libc.so ] || [ -e /usr/lib64/libc.so.? ]; then echo we want lib64; fi we want lib64 {noformat} The above will be a bit more conservative in returning true but still return true for all systems which intentionally use /usr/lib64 (everyone has libc, right?). We could change the comment to: {noformat} # The following code for detecting lib64 was taken from Fedora's # /usr/share/config.site with a modification to check that the # /usr/lib64/libc.so shared library actually exists. This prevents # libdir from being set to /usr/lib64 on 64-bit systems that do not # use /usr/lib64. {noformat} | ||||
| Comments: | By: Asterisk Team (asteriskteam) 2017-03-30 02:18:10.751-0500 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: Corey Farrell (coreyfarrell) 2017-03-30 08:20:20.761-0500 I just checked my one remaining CentOS 6.7 x86_64 system, libc is installed to {{/lib64/libc.so.6}} and {{/lib64/libc-2.12.so}}. Keep in mind this is before systemd so {{/lib64 != /usr/lib64}}. By: Walter Doekes (wdoekes) 2017-04-03 07:16:31.831-0500 This has been fixed by updates to ASTERISK-26705. | ||||