On Thu, Sep 12, 2019 at 6:56 PM Alec Warner <anta...@gentoo.org> wrote:
> > > On Thu, Sep 12, 2019 at 5:14 PM Michael Orlitzky <m...@gentoo.org> wrote: > >> On 9/12/19 5:23 PM, Mike Gilbert wrote: >> > >> > Putting the dependencies in RDEPEND means users get stuck with yet >> > another copy of the code installed, in addition to the copy that is >> > statically linked into all reverse dependencies. >> > >> > It's not a very good solution to the problem. >> > >> >> No argument there. The elegant solution to static linking is to not do >> it. But I guess that's off the table? So now we're trying to find the >> best not very good solution. >> >> > Well I think you end up with a weird tradeoff here. > > Most people who build and package go-based packages use static > compilation, so we could in theory build dynamically linked executables, > but then we diverge from the upstream practice. > Maybe this is the right approach, but I think its a bunch of extra > engineering work (to make things build dynamically) and will be pretty > different from what upstream is expecting. > > > https://docs.google.com/document/d/1nr-TQHw_er6GOQRsF6T43GGhFDelrAP0NqSS_00RgZQ/edit > describes > the new execution modes; it even discusses this very topic! > > "This mode is mainly intended to support distro builders. They can > distribute Go packages or groups of packages as shared libraries, and can > thus update all Go programs by updating the shared libraries, without > requiring the programs to be relinked." > Another thing I neglected to point out is that even with these dynamic libs you end up with toolchain problems. Once you upgrade you go toolchain (goN and go-N+1) and build a new libfoo with go-N+1, it becomes incompatible with binaries built with go-N. Other languages have this problem as well, but its not great and it's a great recipe to hose a system while you are rebuilding your go programs after an upgrade. > > I wonder who pushed for this to Ian, and whether distros ended up using > this kind of target? > > -A > > >
