[asterisk-users] Strange problem with PRI on 64-bit?

[Tzafrir Cohen]

On Wed, Apr 04, 2018 at 11:28:33AM +0000, Tony Mountifield wrote:
> In article <CALD46g3Wz8kajro4_nDE211OsV8PaXfdSZW-G6T2qxjLk-YQWg at mail.gmail.com>,
> Richard Mudgett <rmudgett at digium.com> wrote:
> > 
> > The libpri makefile doesn't install things for 64 bit systems in the right
> > place [1] without your help.  You'll need to specify where to install the
> > library on the command line for your system:
> > 
> > sudo make install libdir=/usr/lib64
> > 
> > 
> > Richard
> > 
> > [1] https://issues.asterisk.org/jira/browse/PRI-100
> 
> Ah, thanks. I did in fact discover the following 64-bit libraries were
> installed into /usr/lib instead of /usr/lib64:
> 
> 1. From DAHDI, libtonezone.so

dahdi-tools 2.11 now uses autoconf. It still installs to /usr/lib or is
it an older version?

> 
> 2. From LibPRI, libpri.so
> 
> 3. From Asterisk, libasteriskssl.so
> 
> I found that running "ldconfig" caused them all to be discovered:
> 
> [root at bridge05 ~]# ldd /usr/sbin/asterisk
>         linux-vdso.so.1 =>  (0x00007ffc77ff9000)
>         libasteriskssl.so.1 => /usr/lib/libasteriskssl.so.1 (0x00007efeae1d4000)
>         libc.so.6 => /lib64/libc.so.6 (0x00007efeade40000)
>         libxml2.so.2 => /usr/lib64/libxml2.so.2 (0x00007efeadaed000)
>         libz.so.1 => /lib64/libz.so.1 (0x00007efead8d7000)
>         libm.so.6 => /lib64/libm.so.6 (0x00007efead653000)
>         libsqlite3.so.0 => /usr/lib64/libsqlite3.so.0 (0x00007efead3c4000)
>         libssl.so.10 => /usr/lib64/libssl.so.10 (0x00007efead158000)
>         libcrypto.so.10 => /usr/lib64/libcrypto.so.10 (0x00007efeacd73000)
>         libdl.so.2 => /lib64/libdl.so.2 (0x00007efeacb6f000)
>         libpthread.so.0 => /lib64/libpthread.so.0 (0x00007efeac952000)
>         libtinfo.so.5 => /lib64/libtinfo.so.5 (0x00007efeac731000)
>         libresolv.so.2 => /lib64/libresolv.so.2 (0x00007efeac517000)
>         /lib64/ld-linux-x86-64.so.2 (0x00007efeae3d6000)
>         libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007efeac2d3000)
>         libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007efeabfec000)
>         libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007efeabde8000)
>         libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007efeabbbc000)
>         libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007efeab9b1000)
>         libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007efeab7ae000)
>         libselinux.so.1 => /lib64/libselinux.so.1 (0x00007efeab58f000)
> [root at bridge05 ~]# ldd /usr/sbin/dahdi_cfg
>         linux-vdso.so.1 =>  (0x00007fff6cbaa000)
>         libtonezone.so.2 => /usr/lib/libtonezone.so.2 (0x00007f862f74a000)
>         libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f862f52d000)
>         libm.so.6 => /lib64/libm.so.6 (0x00007f862f2a9000)
>         libc.so.6 => /lib64/libc.so.6 (0x00007f862ef15000)
>         /lib64/ld-linux-x86-64.so.2 (0x00007f862f97e000)
> [root at bridge05 ~]# ldd /usr/lib/asterisk/modules/chan_dahdi.so
>         linux-vdso.so.1 =>  (0x00007ffe8b1df000)
>         libtonezone.so.2 => /usr/lib/libtonezone.so.2 (0x00007f54adde4000)
>         libpri.so.1.4 => /usr/lib/libpri.so.1.4 (0x00007f54adb68000)
>         libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f54ad94b000)
>         libc.so.6 => /lib64/libc.so.6 (0x00007f54ad5b7000)
>         libm.so.6 => /lib64/libm.so.6 (0x00007f54ad333000)
>         /lib64/ld-linux-x86-64.so.2 (0x00007f54ae2d3000)
> [root at bridge05 ~]#
> 
> So I assumed that all should be ok, otherwise the executables would fail to run
> (I initially discovered this when dahdi_cfg couldn't find libtonezone).
> 
> Would there be any subtle issues with the 64-bit libraries being loaded
> from /usr/lib instead of /usr/lib64?
> 
> Should Asterisk and DAHDI builds also be updated to use /usr/lib64 when
> building on a 64-bit OS? Or the build instructions?

dahdi-tools: not AFAIK.

-- 
               Tzafrir Cohen
+972-50-7952406           mailto:tzafrir.cohen at xorcom.com
http://www.xorcom.com