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?

Improve this question
8
  • 2
    Why do you want to get rid of those? That's normal.
    – forest
    Commented Nov 21, 2018 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
    Commented Nov 21, 2018 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
    Commented Nov 21, 2018 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
    Commented Nov 21, 2018 at 5:13
  • @ forest, I thought there is a compiler flag or something that will resolve it.
    – Noam M
    Commented Nov 21, 2018 at 5:17

1 Answer 1

Reset to default
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!

Improve this answer

Not the answer you're looking for? Browse other questions tagged .