[HN Gopher] Dynamic Linking Best Practices
___________________________________________________________________
Dynamic Linking Best Practices
Author : begriffs
Score : 95 points
Date : 2021-07-04 13:19 UTC (9 hours ago)
(HTM) web link (begriffs.com)
(TXT) w3m dump (begriffs.com)
| janci wrote:
| How this compares to Windows? IIRC it is all handled by the
| executable itself? The kernel32.dll is loaded at known address
| and it has LoadLibrary function to get a handle of DLL and
| GetProcAddress that resolves a function name to a function
| pointer. It loads DLLs from the working directory or system
| directories. No versioning. (But there are some compatibility
| tricks to provide correct version of the library even when the
| dll name does not change)
| rualca wrote:
| This article is a superb treasure trove of experience on dynamic
| linking. Thanks for sharing this gem.
| secondcoming wrote:
| Compiling a shared lib means adding 'fpic', which can mean poor
| codegen if you don't handle your symbol visibility well. By
| default symbols are globally visible and the compiler must assume
| that at runtime you may do an LD_PRELOAD in order to hook into
| some functions, and to do that the functions need to be called
| indirectly rather than directly.
|
| At the very least, add '-fvisibility-inlines-hidden'.
| [deleted]
| marco_craveiro wrote:
| Very interesting. There was also the old Drepper paper, which was
| very good but this seems more accessible. [1]
|
| [1] https://akkadia.org/drepper/dsohowto.pdf
| Digitalis33 wrote:
| As someone who's just now diving into low-level programming on
| unix, this article is just what I needed.
|
| Saving this for future reference.
| lgg wrote:
| It is good article, but I wish it discussed the differences in
| dynamic symbol resolution, which is often a source of subtle
| compatibility issues when porting between POSIX OSes.
|
| Linux uses a flat namespace for linking, where each bind lists
| the symbol name, and then at runtime ld.so searches for that
| symbol based on the library search order.
|
| macOS uses a two level namespace for linking, where each bind
| lists both the symbol name and the installname of the library
| that provides the symbol. This means at runtime the dynamic
| linker does not need use a library search path. This has a number
| of performance and binary compatibility benefits, though it can
| make building software a bit more complex.
|
| Solaris uses a flat namespace, but retrofitted two levelnamespace
| semantics via Direct Binding[1][2]. I am not sure how pervasively
| they are used.
|
| I know there were some efforts to port Solaris Direct Binding
| support to Linux maybe 15 years ago[3][4], but it is a very hard
| change to make without breaking bin and source compatibility for
| projects that depend on insert libraries in the search path for
| partial refinements via interposing symbols.
|
| 1: https://en.wikipedia.org/wiki/Direct_binding 2:
| http://www.linker-aliens.org/blogs/ali/entry/the_cost_of_elf...
| 3: https://lwn.net/Articles/192624/ 4:
| https://bugs.gentoo.org/114008
| pjmlp wrote:
| > The design typically used nowadays for dynamic linking (in BSD,
| MacOS, and Linux) came from SunOS in 1988. The paper Shared
| Libraries in SunOS neatly explains the goals, design, and
| implementation.
|
| Aix shared libraries follow a model similar to Windows, with
| export files.
|
| https://www.ibm.com/docs/en/aix/7.2?topic=memory-creating-sh...
|
| https://www.ibm.com/docs/en/aix/7.2?topic=formats-xcoff-obje...
___________________________________________________________________
(page generated 2021-07-04 23:01 UTC)