0

I have the next so file in /UNI/System/Libs/libmbedcrypto.so.3 directory. When I launch my application, that use libmbedcrypto.so.3 with strace I see:

open("/UNI/System/Libs/tls/v7l/neon/vfp/libmbedcrypto.so.3", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat64("/UNI/System/Libs/tls/v7l/neon/vfp", 0x7ef80610) = -1 ENOENT (No such file or directory)
open("/UNI/System/Libs/tls/v7l/neon/libmbedcrypto.so.3", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat64("/UNI/System/Libs/tls/v7l/neon", 0x7ef80610) = -1 ENOENT (No such file or directory)
open("/UNI/System/Libs/tls/v7l/vfp/libmbedcrypto.so.3", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat64("/UNI/System/Libs/tls/v7l/vfp", 0x7ef80610) = -1 ENOENT (No such file or directory)
open("/UNI/System/Libs/tls/v7l/libmbedcrypto.so.3", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

//...   more stat64 & open

open("/UNI/System/Libs/libmbedcrypto.so.3", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat64("/UNI/System/Libs", {st_mode=S_IFDIR|0777, st_size=4096, ...}) = 0 

How do I get rid of all the open & stat64 calls?

closed as off-topic by Romeo Ninov, RalfFriedl, Jesse_b, Fabby, X Tian Nov 22 '18 at 14:19

  • This question does not appear to be about Unix or Linux within the scope defined in the help center.
If this question can be reworded to fit the rules in the help center, please edit the question.

  • 2
    Why do you want to get rid of those? That's normal. – forest Nov 21 '18 at 5:04
  • 1
    Remove those directories from LD_LIBRARY_PATH? Though what you're seeing is not really a problem, this is working as intended, that's how library name resolution works in Unix/Linux... Why do you think this is a problem? – filbranden Nov 21 '18 at 5:05
  • I know the location of the so file, I want my app to go there first in order to start faster (one core, a lot of process starting at once) – Noam M Nov 21 '18 at 5:06
  • 1
    @NoamM Then you'll have to not use a C library... Write it all in assembly if that's what you want. I mean, the amount of time that is lost with those filesystem checks is negligible. – forest Nov 21 '18 at 5:13
  • @ forest, I thought there is a compiler flag or something that will resolve it. – Noam M Nov 21 '18 at 5:17
1

This is normal. You actually cannot get rid of this without rewriting the program from scratch in assembly, or by writing your own C library to go with it. This is all standard for pretty much any program. Seriously, you do not need to optimize something as inconsequential as this. The amount of time wasted by attempting to access non-existent files is negligible, as you can see in the below syscall trace of true, a program designed only to return 0, from an embedded system:

root@UP-1044:~# strace -T -e trace=open true
open("/tmp/t/usr/lib/libgcc_s.so.1", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory) <0.000643>
open("/tmp/t/lib/libgcc_s.so.1", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory) <0.000861>
open("/lib/libgcc_s.so.1", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 <0.000208>
+++ exited with 0 +++

The amount of time wasted on each of these syscalls seems to be less than a single millisecond!

Not the answer you're looking for? Browse other questions tagged or ask your own question.