Opened 12 years ago
Closed 12 years ago
#3703 closed Enhancement (wontfix)
libtransmission as a shared object
Reported by: | zebulon501 | Owned by: | charles |
---|---|---|---|
Priority: | Normal | Milestone: | Sometime |
Component: | libtransmission | Version: | 2.11 |
Severity: | Normal | Keywords: | |
Cc: |
Description (last modified by charles)
Now that transmission-create & co exist, it might make sense to have libtransmission as a shared object and not statically linked to each binary.
Change History (6)
comment:1 Changed 12 years ago by charles
- Description modified (diff)
- Milestone changed from None Set to Sometime
- Status changed from new to assigned
comment:2 Changed 12 years ago by jch
Charles, I don't recommend that. Unless you're willing to spend a lot of time dealing with binary compatibility issues, a shared library will cause trouble without end.
--jch
comment:3 Changed 12 years ago by charles
jch, can you give an example of this?
comment:4 Changed 12 years ago by charles
jch, can you give an example of this?
comment:5 Changed 12 years ago by jch
I'm not sure what you're asking for.
If you create a dynamic library, you're committing to either preserve the ABI, or increase the SONAME. There is no such requirement with static libraries -- you just make sure you update the .h in sync with the library.
So there's a non-negligible maintenance cost. On the other hand, the benefits are non-existent -- you're just saving a few hundred kilobytes of disk space by sharing some code between the daemon and the GUI client.
--jch
comment:6 Changed 12 years ago by jordan
- Resolution set to wontfix
- Status changed from assigned to closed
Thanks :)
I think you're probably right about this.