Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Beginner
915 Views

isdct 3.0.0 library problem

Jump to solution

isdct-3.0.0.400-15.x86_64.rpm doesn't actually seem to work (appears to be a bad soname in a dependent lib?)..

# isdct show -intelssd

Error: Failed to find valid library: libIntel.SSDFeatures.so.2.0.0

But strace shows:

17:50:26.432200 open("/usr/lib/isdct/libIntel.SSDFeatures.so.2.0.0", O_RDONLY) = 3 <0.000016>

17:50:26.432311 lseek(3, 0, SEEK_END) = 6667728 <0.000013>

17:50:26.432353 lseek(3, 0, SEEK_CUR) = 6667728 <0.000011>

17:50:26.432415 lseek(3, 0, SEEK_SET) = 0 <0.000008>

17:50:26.432458 mmap(NULL, 6668288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fac68498000 <0.000010>

17:50:26.437090 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0C\n\0\0\0\0\0"..., 6667728) = 6667728 <0.001782>

17:50:26.438945 close(3) = 0 <0.000009>

17:50:26.459653 munmap(0x7fac68498000, 6668288) = 0 <0.000581>

17:50:26.460320 fstat(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 0), ...}) = 0 <0.000008>

17:50:26.460370 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fac6a399000 <0.000012>

17:50:26.460420 write(1, "Error: Failed to find valid libr"..., 67Error: Failed to find valid library: libIntel.SSDFeatures.so.2.0.0

) = 67 <0.000018>

Huh?

# readelf -d /usr/lib/isdct/libIntel.SSDFeatures.so.2.0.0 | grep SONAME

0x000000000000000e (SONAME) Library soname: [tdk_interface_dll.so]

Hmm. dlopen() fails because the SONAME is wrong I presume?

0 Kudos

Accepted Solutions
Highlighted
Beginner
7 Views

Re: isdct 3.0.0 library problem

Jump to solution

Hmm, while the SONAME is indeed odd, it isn't the cause of this afterall. I'm repackaging these as DEBs before consuming and dh_strip (which just does strip --remove-section=.note --remove-section=.comment --strip-unneeded) seems to be mangling something (loses 80 bytes even when it doesn't drop any sections). Easy enough to disable in the repackaging.

Any chance Intel will provide "official" DEBs sometime soon?

Amusingly, the .comment tags suggest that the linux binaries are actually built on Ubuntu but then packaged into RPMs?

$ objdump -s --section .comment usr/lib/isdct/libIntel.SSDFeatures.so.1.2.0

usr/lib/isdct/libIntel.SSDFeatures.so.1.2.0: file format elf64-x86-64

Contents of section .comment:

0000 4743433a 20285562 756e7475 20342e34 GCC: (Ubuntu 4.4

0010 2e332d34 7562756e 7475352e 31292034 .3-4ubuntu5.1) 4

0020 2e342e33 00 .4.3.

View solution in original post

0 Kudos
1 Reply
Highlighted
Beginner
8 Views

Re: isdct 3.0.0 library problem

Jump to solution

Hmm, while the SONAME is indeed odd, it isn't the cause of this afterall. I'm repackaging these as DEBs before consuming and dh_strip (which just does strip --remove-section=.note --remove-section=.comment --strip-unneeded) seems to be mangling something (loses 80 bytes even when it doesn't drop any sections). Easy enough to disable in the repackaging.

Any chance Intel will provide "official" DEBs sometime soon?

Amusingly, the .comment tags suggest that the linux binaries are actually built on Ubuntu but then packaged into RPMs?

$ objdump -s --section .comment usr/lib/isdct/libIntel.SSDFeatures.so.1.2.0

usr/lib/isdct/libIntel.SSDFeatures.so.1.2.0: file format elf64-x86-64

Contents of section .comment:

0000 4743433a 20285562 756e7475 20342e34 GCC: (Ubuntu 4.4

0010 2e332d34 7562756e 7475352e 31292034 .3-4ubuntu5.1) 4

0020 2e342e33 00 .4.3.

View solution in original post

0 Kudos