7 ms·

I've been looking for something like this to send to some C++ newbies. This is almost what I need but not exactly. Is there something similar that explains h

by joker3 8y ago

I've been looking for something like this to send to some C++ newbies. This is almost what I need but not exactly. Is there something similar that explains how libraries work?

aidenn0 8y ago
Libraries are just a bundle of .o files (e.g. run "ar t /usr/lib/x86_64-linux-gnu/libpython2.7.a" on an ubuntu with devtools installed and you'll see all the .o files that are in libpython2.7). The special thing about them though is that the linker will not include any .o files for which no symbols are referenced. You can think of the typical linker algorithm as follows: If I am missing a symbol X scan through all not used objects in each library until you find it, then include that .o file. Now check if any symbols are missing again and repeat until done.
- colanderman 8y ago
  > Now check if any symbols are missing again and repeat until done. That properly describes linking using --start-group/--end-group. Without those flags, the process is closer to "look in the first .a file for definitions of all currently undefined symbols; then look in the next .a file for definitions of remaining undefined symbols; etc.". The difference becomes apparent if you link chains of libraries in the wrong order, or if you have cyclic dependencies between libraries; normally they will not be resolved unless you use the grouping flags. (But really, you should avoid making such cycles in the first place!)
  - jacobush 8y ago
    This is the first explanation I have understood of this perplexing phenomenon.
  - aidenn0 8y ago
    Thanks for the correction. I was posting that from my phone without any references in front of me.
- frutiger 8y ago
  Not only that, but add any undefined symbols from that .o file to the list of symbols I need to find.
- malkia 8y ago
  And as we know this has a side effect on C++ with globally constructed (but unreferenced) objects. These would get "dropped" essentially when linking, and they come from a library.
- geezerjay 8y ago
  > Libraries are just a bundle of .o files That's a very simplistic and error-prone description of what a library is supposed to be. Even in high-level descriptions, it's very important to be aware of the fundamental differences between static and dynamic libraries, and how they are integrated in the build process, which has a fundamental role in basic tasks such as deploying applications.
- roel_v 8y ago
  "Libraries are just a bundle of .o files" Static libraries are more or less that yes (at least, that mental model is sufficient for pretty much all day to day use of them), but dynamic libraries aren't, at all. As an aside, I found it very weird that the OP claimed that 'nobody uses static linking'. Wut? Static linking is everywhere (so is dynamic linking, of course, but implying that one is merely a quaint remainder from the past is just so odd).
  - aidenn0 8y ago
    There has been a heavy bias towards shared objects in glibc and the GNU userspace utilities for a long time. Today that mostly means dynamic libraries (there are also statically linked shared objects, but those are mostly a quaint reminder of the past). I don't hate dynamic linking as much as I used to, but it is still a peeve of mine. Linux is one of the most backwards compatible kernels, but the heavy usage of dynamic linking means that a linux program from 20 years ago either won't work at all, or will be buggy. A statically linked program from 20 years ago will work (but possibly won't have sound; though it's possible to get either alsa or pulse audio to emulate OSS and then even sound will work).
- FabHK 8y ago
  Presumably what you say makes sense to people that already know what you're saying, but to me, reading > a bundle of .o files [note ".o"] > e.g. [...] libpython2.7.a [note ".a"] adds, rather than resolves, confusion.
  - aidenn0 8y ago
    I was hoping in the context of discussing this article, it would be clear what a .o file is. Discussing libraries without that knowledge is hard, so i just have to assume the person asking the question knows it. .a is an extension for one type of library, sorry if that confused you, but it can be ignored for the purposes of this explanation.
- berti 8y ago
  There is a really good paper by Ulrich Drepper on dynamic linking with ELF and glibc (+ a bunch of other important stuff if you're writing libraries) [1], but it's way too low level for what GP wants. I'm sure there must be something simpler around but I haven't seen it. [1] https://akkadia.org/drepper/dsohowto.pdf https://akkadia.org/drepper/dsohowto.pdf
green7ea 8y ago
That's a good point. I think I could add a section that quickly describes how linking works and gives a few examples using ldd. I'm busy for the next few days but this is near the top of my TODO. Thanks for the feedback :-)
geezerjay 8y ago
> Is there something similar that explains how libraries work? Check out this HN discussion on an ebook on linking and loading. The book itself is a treat, and the discussion around the book is very informative as well. https://news.ycombinator.com/item?id=18424233 https://news.ycombinator.com/item?id=18424233

by joker3 8y ago

I've been looking for something like this to send to some C++ newbies. This is almost what I need but not exactly. Is there something similar that explains how libraries work?

aidenn0 8y ago

Libraries are just a bundle of .o files (e.g. run "ar t /usr/lib/x86_64-linux-gnu/libpython2.7.a" on an ubuntu with devtools installed and you'll see all the .o files that are in libpython2.7). The special thing about them though is that the linker will not include any .o files for which no symbols are referenced. You can think of the typical linker algorithm as follows: If I am missing a symbol X scan through all not used objects in each library until you find it, then include that .o file. Now check if any symbols are missing again and repeat until done.

colanderman 8y ago
> Now check if any symbols are missing again and repeat until done. That properly describes linking using --start-group/--end-group. Without those flags, the process is closer to "look in the first .a file for definitions of all currently undefined symbols; then look in the next .a file for definitions of remaining undefined symbols; etc.". The difference becomes apparent if you link chains of libraries in the wrong order, or if you have cyclic dependencies between libraries; normally they will not be resolved unless you use the grouping flags. (But really, you should avoid making such cycles in the first place!)
- jacobush 8y ago
  This is the first explanation I have understood of this perplexing phenomenon.
- aidenn0 8y ago
  Thanks for the correction. I was posting that from my phone without any references in front of me.
frutiger 8y ago
Not only that, but add any undefined symbols from that .o file to the list of symbols I need to find.
malkia 8y ago
And as we know this has a side effect on C++ with globally constructed (but unreferenced) objects. These would get "dropped" essentially when linking, and they come from a library.
geezerjay 8y ago
> Libraries are just a bundle of .o files That's a very simplistic and error-prone description of what a library is supposed to be. Even in high-level descriptions, it's very important to be aware of the fundamental differences between static and dynamic libraries, and how they are integrated in the build process, which has a fundamental role in basic tasks such as deploying applications.
roel_v 8y ago
"Libraries are just a bundle of .o files" Static libraries are more or less that yes (at least, that mental model is sufficient for pretty much all day to day use of them), but dynamic libraries aren't, at all. As an aside, I found it very weird that the OP claimed that 'nobody uses static linking'. Wut? Static linking is everywhere (so is dynamic linking, of course, but implying that one is merely a quaint remainder from the past is just so odd).
- aidenn0 8y ago
  There has been a heavy bias towards shared objects in glibc and the GNU userspace utilities for a long time. Today that mostly means dynamic libraries (there are also statically linked shared objects, but those are mostly a quaint reminder of the past). I don't hate dynamic linking as much as I used to, but it is still a peeve of mine. Linux is one of the most backwards compatible kernels, but the heavy usage of dynamic linking means that a linux program from 20 years ago either won't work at all, or will be buggy. A statically linked program from 20 years ago will work (but possibly won't have sound; though it's possible to get either alsa or pulse audio to emulate OSS and then even sound will work).
FabHK 8y ago
Presumably what you say makes sense to people that already know what you're saying, but to me, reading > a bundle of .o files [note ".o"] > e.g. [...] libpython2.7.a [note ".a"] adds, rather than resolves, confusion.
- aidenn0 8y ago
  I was hoping in the context of discussing this article, it would be clear what a .o file is. Discussing libraries without that knowledge is hard, so i just have to assume the person asking the question knows it. .a is an extension for one type of library, sorry if that confused you, but it can be ignored for the purposes of this explanation.
berti 8y ago
There is a really good paper by Ulrich Drepper on dynamic linking with ELF and glibc (+ a bunch of other important stuff if you're writing libraries) [1], but it's way too low level for what GP wants. I'm sure there must be something simpler around but I haven't seen it. [1] https://akkadia.org/drepper/dsohowto.pdf https://akkadia.org/drepper/dsohowto.pdf

green7ea 8y ago

That's a good point. I think I could add a section that quickly describes how linking works and gives a few examples using ldd. I'm busy for the next few days but this is near the top of my TODO. Thanks for the feedback :-)

geezerjay 8y ago

> Is there something similar that explains how libraries work? Check out this HN discussion on an ebook on linking and loading. The book itself is a treat, and the discussion around the book is very informative as well. https://news.ycombinator.com/item?id=18424233 https://news.ycombinator.com/item?id=18424233