3 ms·

The primary advantage is efficiency, although this effect is generally small. Often there are many symbols that aren't needed for a particular program run so re

The primary advantage is efficiency, although this effect is generally small. Often there are many symbols that aren't needed for a particular program run so resolving and relocating them is wasted effort. If you're interested you can use LD_DEBUG=statistics to get some details on this. Here's some abbreviated output: $ LD_DEBUG=statistics nmap -V 32564: total startup time in dynamic loader: 8917260 cycles 32564: final number of relocations: 2449 $ LD_BIND_NOW=1 LD_DEBUG=statistics nmap -V 32565: total startup time in dynamic loader: 12511900 cycles 32565: final number of relocations: 4730 Another difference between lazy and now is that if there is some symbol resolution problem, but the application never actually references that symbol, then the process can still run. This is either an advantage or a disadvantage depending on how you look at it.

umbs 9y ago
Genuine question. How does one acquire (and retain) this depth of knowledge. I work on low-level system software (C programming). Having good understanding of build system (make, cmake), dependencies and shared library knowledge is highly desired in my field. But this is very hard core. Really interested in the path leading up to this.
- aleden 9y ago
  My strategy is to work hard on my ability to read other people's code. I think I've noticed that the better I get at that, the more "deeply" I understand the environment. Documentation also frequently sucks, probably because it's hard to keep it sync'ed up with the code.
- clarry 9y ago
  Not hard core. Just out of the way, in the same way that assembly is out of the way for most C programmers. They don't need to deal with it, so they don't. If you want to learn, it is not hard at all. All it takes is curiosity. Of course, hitting a bug in ld.so or having to debug a kinky issue at the instruction level can feed such curiosity. Apart from that, being in the right place helps. That could be a mailing list or some other channel where these tools are talked about. Out of curiosity, what software do you work on? I have a very difficult time finding a C job, let alone one where this type of information would be valued.
  - umbs 9y ago
    Well said. This knowledge is "out of the way" and with effort can be gained. I work in networking industry (as software dev). Think Juniper, Cisco, Brocade etc. This industry needs only C devs.

umbs 9y ago

Genuine question. How does one acquire (and retain) this depth of knowledge. I work on low-level system software (C programming). Having good understanding of build system (make, cmake), dependencies and shared library knowledge is highly desired in my field. But this is very hard core. Really interested in the path leading up to this.

aleden 9y ago
My strategy is to work hard on my ability to read other people's code. I think I've noticed that the better I get at that, the more "deeply" I understand the environment. Documentation also frequently sucks, probably because it's hard to keep it sync'ed up with the code.
clarry 9y ago
Not hard core. Just out of the way, in the same way that assembly is out of the way for most C programmers. They don't need to deal with it, so they don't. If you want to learn, it is not hard at all. All it takes is curiosity. Of course, hitting a bug in ld.so or having to debug a kinky issue at the instruction level can feed such curiosity. Apart from that, being in the right place helps. That could be a mailing list or some other channel where these tools are talked about. Out of curiosity, what software do you work on? I have a very difficult time finding a C job, let alone one where this type of information would be valued.
- umbs 9y ago
  Well said. This knowledge is "out of the way" and with effort can be gained. I work in networking industry (as software dev). Think Juniper, Cisco, Brocade etc. This industry needs only C devs.