On Wednesday, 27 June 2018 10:29:38 PDT Thiago Macieira wrote:
On Tuesday, 26 June 2018 23:50:15 PDT Nesius, Robert A wrote:
> You're using a side-effect of the low "avx-ness" of the plugins to
> black-list. I'm worried that might have unintended consequences down the
> road. Better to take a pattern to exclude from the move?
I didn't understand what you meant. Can you give an example of what you're
Update: after speaking to Rob, we understood each other, but he threw a wrench
into my script. What happens to private libraries that don't live in directly
under $libdir? Just run /usr/lib64/*/*.so.* on your system and you'll find
several. So it makes sense to put libraries in haswell/ subdirs too.
How do you tell a library apart from a plugin? My first idea was ".so file is
a symlink, it's a library; otherwise it's a plugin" but that already fails
Samba. libtool permits creating libraries like that. The correct way is to
detect the presence of the DT_SONAME field in the ELF dynamic section. I'll
try to hack this tonight.
% ldd =samba | grep libtevent.so.0
libtevent.so.0 => /usr/lib64/samba/libtevent.so.0 (0x00007f1d322e7000)
% eu-readelf -d =samba | grep -e path -e libtevent.so.0
NEEDED Shared library: [libtevent.so.0]
RUNPATH Library runpath: [/usr/lib64/samba:/usr/lib64]
% LD_DEBUG=libs samba |& sed '/RUNPATH/q'
130: find library=libpthread.so.0 ; searching
130: search path=/usr/lib64/samba/tls/haswell/x86_64:/usr/lib64/
lib64/samba (RUNPATH from file samba)
As can be seen from these commands, the dynamic linker is searching for
libraries in /usr/lib64/samba/haswell, so it would make sense to put libraries
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center