{"thread":{"id":"51290","subject":"Reducing git size by building libgit.so","startedAt":"2019-06-11T20:02:02Z","lastAt":"2019-06-13T19:19:33Z","messageCount":12,"participants":["Elmar Pruesse","brian m. carlson","Duy Nguyen","Ævar Arnfjörð Bjarmason","SZEDER Gábor","Paul Smith","Johannes Schindelin","Junio C Hamano","Johannes Sixt"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"377024","messageId":"21f1f334-755e-3283-d0da-ec0ab9231cfc@ucdenver.edu","threadId":"51290","inReplyTo":null,"subject":"Reducing git size by building libgit.so","fromName":"Elmar Pruesse","fromEmail":"p@ucdenver.edu","sentAt":"2019-06-11T19:52:18Z","receivedAt":"2019-06-11T20:02:02Z","isPatch":false,"sender":{"key":"p@ucdenver.edu","avatar":null},"body":"Hi!\n\nThe total compiled size of libexec/git-core is currently somewhere \naround 30 MB. This is largely due to a number of binaries linking \nstatically against libgit.a. For some folks, every byte counts. I \nmeddled with the Makefile briefly to make it build and use a libgit.so \ninstead, which dropped package size down to 5MB.\n\nAre there, beyond the ~20 ms in extra startup time and the slightly \nbigger hassle with DSO locations, reasons for the choice to link statically?\n\nbest,\n\nElmar\n\n"},{"id":"377045","messageId":"20190611234815.GB8616@genre.crustytoothpaste.net","threadId":"51290","inReplyTo":"21f1f334-755e-3283-d0da-ec0ab9231cfc@ucdenver.edu","subject":"Re: Reducing git size by building libgit.so","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2019-06-11T23:48:19Z","receivedAt":"2019-06-11T23:48:27Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2019-06-11 at 19:52:18, Elmar Pruesse wrote:\n> Hi!\n> \n> The total compiled size of libexec/git-core is currently somewhere\n> around 30 MB. This is largely due to a number of binaries linking\n> statically against libgit.a. For some folks, every byte counts. I\n> meddled with the Makefile briefly to make it build and use a libgit.so\n> instead, which dropped package size down to 5MB.\n> \n> Are there, beyond the ~20 ms in extra startup time and the slightly\n> bigger hassle with DSO locations, reasons for the choice to link statically?\n\nI think the reason is that libgit is not API stable and we definitely\ndon't want people linking against it. Before libgit2 existed, projects\nlike cgit built their own libgit and it required pinning to a specific\nversion of Git.\n\nAlso, some people install Git into their home directories, and a shared\nlibrary means that they'll have to use LD_LIBRARY_PATH (or equivalent)\nto run Git.\n\nFinally, we have support for a runtime relocatable Git which can be run\nout of any path and still automatically find its dependent binaries.\nThat won't work with a shared library.\n\nSo if we did allow for building a shared library, it would have to be an\noption that defaulted to off, I think.\n-- \nbrian m. carlson: Houston, Texas, US\nOpenPGP: https://keybase.io/bk2204\n"},{"id":"377055","messageId":"CACsJy8BxdvOrc28_JhAARzJdOqyqWZaFX8DoPjEr4BCe-sRqsg@mail.gmail.com","threadId":"51290","inReplyTo":"20190611234815.GB8616@genre.crustytoothpaste.net","subject":"Re: Reducing git size by building libgit.so","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2019-06-12T09:29:32Z","receivedAt":"2019-06-12T09:30:00Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Wed, Jun 12, 2019 at 2:11 PM brian m. carlson\n<sandals@crustytoothpaste.net> wrote:\n>\n> On 2019-06-11 at 19:52:18, Elmar Pruesse wrote:\n> > Hi!\n> >\n> > The total compiled size of libexec/git-core is currently somewhere\n> > around 30 MB. This is largely due to a number of binaries linking\n> > statically against libgit.a. For some folks, every byte counts. I\n> > meddled with the Makefile briefly to make it build and use a libgit.so\n> > instead, which dropped package size down to 5MB.\n> >\n> > Are there, beyond the ~20 ms in extra startup time and the slightly\n> > bigger hassle with DSO locations, reasons for the choice to link statically?\n>\n> I think the reason is that libgit is not API stable and we definitely\n> don't want people linking against it.\n\nHaving .so files does not mean it's stable API though. If we don't\never install header files, there's no way for outside people to use it\n(people who dlopen() it anyway deserve whatever they get). I do agree\nwith some hassles from .so files though.\n\nIf installation size is a problem I think we can still shrink it a bit\ndown. Some non-builtin commands (fast-import, sh-i18n--subst...) could\nbe merged back in \"git\" binary. Some other for remote side (or\nbackground daemons) could also be bundled together unless there's\nsecurity concerns.\n\nWe could also have a look at function distribution in libgit.a. I'm\nsurprised git-credential-store is 5.6 MB on my machine. We probably\npull more stuff than needed somewhere due to dependency between .o\nfiles.\n\n> Before libgit2 existed, projects\n> like cgit built their own libgit and it required pinning to a specific\n> version of Git.\n>\n> Also, some people install Git into their home directories, and a shared\n> library means that they'll have to use LD_LIBRARY_PATH (or equivalent)\n> to run Git.\n>\n> Finally, we have support for a runtime relocatable Git which can be run\n> out of any path and still automatically find its dependent binaries.\n> That won't work with a shared library.\n>\n> So if we did allow for building a shared library, it would have to be an\n> option that defaulted to off, I think.\n> --\n> brian m. carlson: Houston, Texas, US\n> OpenPGP: https://keybase.io/bk2204\n\n\n\n-- \nDuy\n"},{"id":"377056","messageId":"87y32787k9.fsf@evledraar.gmail.com","threadId":"51290","inReplyTo":"21f1f334-755e-3283-d0da-ec0ab9231cfc@ucdenver.edu","subject":"Re: Reducing git size by building libgit.so","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2019-06-12T09:41:10Z","receivedAt":"2019-06-12T09:41:15Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Tue, Jun 11 2019, Elmar Pruesse wrote:\n\n> Hi!\n>\n> The total compiled size of libexec/git-core is currently somewhere\n> around 30 MB. This is largely due to a number of binaries linking\n> statically against libgit.a. For some folks, every byte counts. I\n> meddled with the Makefile briefly to make it build and use a libgit.so\n> instead, which dropped package size down to 5MB.\n>\n> Are there, beyond the ~20 ms in extra startup time and the slightly\n> bigger hassle with DSO locations, reasons for the choice to link statically?\n\nbrian mentioned API stability. I'd be fine with having a *.so shipped\nwith git. We'd document the API non-stability, and of course it's GPL so\nyou can only link other GPL programs to it, but if people would be fine\nwith still using it and very closely following git development as we\nbreak their API/ABI why not.\n\nHave you looked at INSTALL_SYMLINKS & friends? I.e. maybe you're\nmeasuring size without accounting for most of the binaries being\nhardlinks to the same thing.\n\nWe still have some stand-alone binaries, but IIRC there's under 5 of\nthose with INSTALL_SYMLINKS. We could probably also just make those\nbuilt-ins to get the rest of the size benefits.\n\nI.e. we'd just have one git binary, everything else symlinking to that,\nand we'd route to the right program by inspecting argv, which we mostly\ndo already.\n"},{"id":"377057","messageId":"CACsJy8Ce9exNKEYojo8Uu6WjyjSGN2imO-8Z4cXa-FGkXs4GJQ@mail.gmail.com","threadId":"51290","inReplyTo":"87y32787k9.fsf@evledraar.gmail.com","subject":"Re: Reducing git size by building libgit.so","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2019-06-12T09:46:33Z","receivedAt":"2019-06-12T09:47:01Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Wed, Jun 12, 2019 at 4:42 PM Ævar Arnfjörð Bjarmason\n<avarab@gmail.com> wrote:\n> I.e. we'd just have one git binary, everything else symlinking to that,\n> and we'd route to the right program by inspecting argv, which we mostly\n> do already.\n\nIf I remember correctly libcurl.so startup time was the reason it's\nsplit out of \"git\" binary, so we can't just merge everything into one\n(*). But yeah merging some back is not a bad idea.\n\n(*) but maybe \"git\" binary has gotten much slower overall, or\nlibcurl.so much faster that it does not matter anymore. That problem\nwas like 10 years ago.\n-- \nDuy\n"},{"id":"377058","messageId":"20190612102537.GI4012@szeder.dev","threadId":"51290","inReplyTo":"87y32787k9.fsf@evledraar.gmail.com","subject":"Re: Reducing git size by building libgit.so","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2019-06-12T10:25:37Z","receivedAt":"2019-06-12T10:25:43Z","isPatch":false,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"On Wed, Jun 12, 2019 at 11:41:10AM +0200, Ævar Arnfjörð Bjarmason wrote:\n> On Tue, Jun 11 2019, Elmar Pruesse wrote:\n> > The total compiled size of libexec/git-core is currently somewhere\n> > around 30 MB. This is largely due to a number of binaries linking\n> > statically against libgit.a. For some folks, every byte counts.\n\nI wonder whether those folks actually need such non-builtin git\nbinaries like 'git-shell' or 'git-daemon' in the first place.\n\n\n> We still have some stand-alone binaries, but IIRC there's under 5 of\n> those with INSTALL_SYMLINKS. We could probably also just make those\n> built-ins to get the rest of the size benefits.\n> \n> I.e. we'd just have one git binary, everything else symlinking to that,\n> and we'd route to the right program by inspecting argv, which we mostly\n> do already.\n\nLet's not forget that commands like 'git-daemon' and 'git-shell' are\nbetter left as stand-alone programs.\n\n"},{"id":"377077","messageId":"9c488ce8c1e1e6d6d4c343b0b40c8a64c8147a7f.camel@mad-scientist.net","threadId":"51290","inReplyTo":"20190611234815.GB8616@genre.crustytoothpaste.net","subject":"Re: Reducing git size by building libgit.so","fromName":"Paul Smith","fromEmail":"paul@mad-scientist.net","sentAt":"2019-06-12T13:57:43Z","receivedAt":"2019-06-12T14:21:17Z","isPatch":false,"sender":{"key":"paul@mad-scientist.net","avatar":"https://avatars.githubusercontent.com/u/109636?v=4"},"body":"On Tue, 2019-06-11 at 23:48 +0000, brian m. carlson wrote:\n> Also, some people install Git into their home directories, and a\n> shared library means that they'll have to use LD_LIBRARY_PATH (or\n> equivalent) to run Git.\n\nI don't have strong feeling about .so's although obviously less disk\nspace used is always a good thing, everything else being equal.\n\nHowever, the above concern isn't actually an issue.  You can install\nthe .so in a known location relative to the binaries, then link the\nbinaries with an RPATH setting using $ORIGIN (or the equivalent on\nMacOS which does exist but I forget the name).  On Windows, DLLs are\ninstalled in the same directory as the binary, typically.\n\nAllowing relocatable binaries with .so dependencies without requiring\nLD_LIBRARY_PATH settings is a solved problem, to the best of my\nunderstanding.\n\n\nOne thing to think about is that runtime loading a .so can take some\ntime if it has lots of public symbols.  If someone really wanted to do\nthis, the ideal thing would be to make all symbols hidden except those\nneeded by the binary front-ends and have those be very small shells\nthat just had a very limited number of entry points into the .so.\n\nMaybe for git this doesn't matter but for some projects I've worked on\nthe time to dlopen() a library was a blocking issue that the above\nprocedure solved nicely.\n\n"},{"id":"377134","messageId":"nycvar.QRO.7.76.6.1906130914250.42@tvgsbejvaqbjf.bet","threadId":"51290","inReplyTo":"9c488ce8c1e1e6d6d4c343b0b40c8a64c8147a7f.camel@mad-scientist.net","subject":"Re: Reducing git size by building libgit.so","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2019-06-13T07:51:05Z","receivedAt":"2019-06-13T16:34:38Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Paul,\n\nOn Wed, 12 Jun 2019, Paul Smith wrote:\n\n> On Tue, 2019-06-11 at 23:48 +0000, brian m. carlson wrote:\n> > Also, some people install Git into their home directories, and a\n> > shared library means that they'll have to use LD_LIBRARY_PATH (or\n> > equivalent) to run Git.\n>\n> I don't have strong feeling about .so's although obviously less disk\n> space used is always a good thing, everything else being equal.\n>\n> However, the above concern isn't actually an issue.  You can install\n> the .so in a known location relative to the binaries, then link the\n> binaries with an RPATH setting using $ORIGIN (or the equivalent on\n> MacOS which does exist but I forget the name).\n\nHassles aside, you mentioned Linux and macOS. What about literally *all*\nthe other platforms we support? Like AIX, NonStop, HP/UX, etc?\n\nSure, you can hunt down all of them, and maybe even come up with a\nworkaround for platforms that do not have a $ORIGIN equivalent. You can\npile workaround on workaround all you want.\n\nIn the end, it seems to be a clear indicator that this is a complicator's\nglove, and the only reasonably simple way forward would be to either leave\nthings as-are, or have an *opt-in* to build a shared libgit.\n\nBut.\n\nAnd this is a really big but.\n\nWhile you can try to document _all you want_ how libgit.so is not supposed\nto be used as a library, how its API is not an API or at least not a\nstable one, if you have _some_ experience with software development you\nwill know that it won't matter one bit. It _will_ be used, people _will_\ncomplain, and it will turn out to simply not have been a good idea in the\nfirst place.\n\n> On Windows, DLLs are installed in the same directory as the binary,\n> typically.\n>\n> Allowing relocatable binaries with .so dependencies without requiring\n> LD_LIBRARY_PATH settings is a solved problem, to the best of my\n> understanding.\n\nYou're probably right, as long as you restrict your view to mainstream\nOperating Systems.\n\nTo put things into perspective, you might be interested in reading up on\nhttps://github.com/git/git/commit/0f50c8e32c87 (Makefile: remove the\nNO_R_TO_GCC_LINKER flag, 2019-05-17) and related commit history.\n\nSure, you could still argue that it is a \"solved\" problem. Where \"solved\"\nis a different term than \"desirable\".\n\n> One thing to think about is that runtime loading a .so can take some\n> time if it has lots of public symbols.  If someone really wanted to do\n> this, the ideal thing would be to make all symbols hidden except those\n> needed by the binary front-ends and have those be very small shells\n> that just had a very limited number of entry points into the .so.\n\nThat would fall squarely into the \"pile on workaround on workaround\"\ncategory I mentioned above.\n\n> Maybe for git this doesn't matter but for some projects I've worked on\n> the time to dlopen() a library was a blocking issue that the above\n> procedure solved nicely.\n\nSure, sometimes you cannot control whether it is an ill-designed `.so` you\nneed to consume.\n\nAs far as Git is concerned, this is not the case. At least when you look\nat libgit.\n\nWhen you look at libcurl, it is a different matter. But then, we do not\nneed to play RPATH games there: we expect it to be in the system's\npreferred location.\n\nBTW Duy hinted at problems with libcurl that made us split apart\n`git-remote-https` from the main `git` executable. The full story is here:\n\n1. The Linus complained about some \"crazy\" shared library loading behavior\n   five months before Christmas 2009:\n\n   https://public-inbox.org/git/alpine.LFD.2.01.0907241349390.3960@localhost.localdomain/\n\n2. Daniel Barkalow was working on some \"foreign VCS\" support and thought\n   that HTTPS/HTTP support could be handled via the same route, to avoid\n   having to load libcurl for every Git operation no matter what:\n\n   https://public-inbox.org/git/alpine.LNX.2.00.0907242242310.2147@iabervon.org/\n\n3. Daniel then sent a patch series about two weeks later:\n\n   https://public-inbox.org/git/alpine.LNX.2.00.0908050052390.2147@iabervon.org/\n\n4. Those patches were accepted via cd03eebbfdae (Merge branch\n   'db/vcs-helper', 2009-09-13)\n\nSo yes, I think that a patch or patch series to turn libgit.a into\nlibgit.so would need to be crafted *very* carefully, and _in the least_\noffer a sound performance analysis in the commit messages.\n\nIt would obviously need to be proven beyond doubt that the startup time\ndoes not deteriorate noticeably, otherwise the patch (series) would likely\nbe rejected.\n\nCiao,\nJohannes\n"},{"id":"377146","messageId":"20190612233142.GC8616@genre.crustytoothpaste.net","threadId":"51290","inReplyTo":"9c488ce8c1e1e6d6d4c343b0b40c8a64c8147a7f.camel@mad-scientist.net","subject":"Re: Reducing git size by building libgit.so","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2019-06-12T23:31:42Z","receivedAt":"2019-06-13T17:01:52Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2019-06-12 at 13:57:43, Paul Smith wrote:\n> On Tue, 2019-06-11 at 23:48 +0000, brian m. carlson wrote:\n> > Also, some people install Git into their home directories, and a\n> > shared library means that they'll have to use LD_LIBRARY_PATH (or\n> > equivalent) to run Git.\n> \n> I don't have strong feeling about .so's although obviously less disk\n> space used is always a good thing, everything else being equal.\n> \n> However, the above concern isn't actually an issue.  You can install\n> the .so in a known location relative to the binaries, then link the\n> binaries with an RPATH setting using $ORIGIN (or the equivalent on\n> MacOS which does exist but I forget the name).  On Windows, DLLs are\n> installed in the same directory as the binary, typically.\n> \n> Allowing relocatable binaries with .so dependencies without requiring\n> LD_LIBRARY_PATH settings is a solved problem, to the best of my\n> understanding.\n\nThis is possible to do, but it's not especially portable.  People use\nvarious C toolchains to compile our code, which may or may not have easy\naccess to linker flags.  The proper syntax also varies depending on\nwhether you're using ELF, Mach-O, PE[0], or another object format.  And\nDebian tries hard to avoid RPATH settings[1], so we'd need to be sure to\nhave an option not to set it.\n\nNone of these are intractable problems, but there's not simply an easy\nsolution that we can magically set that will work everywhere.  If we\nwere using autoconf and friends exclusively, this would be easier, but\nwe're not.  So someone is welcome to attack these problems with a set of\npatches, but I expect it to be fairly involved to get all the corner\ncases right if we want to make it the default.\n\n[0] AFAIUI, Windows doesn't have RPATH-like functionality, and from what\nI've read, the same-directory behavior may be going away due to security\nconcerns.  I don't use Windows, so any solution there is fine as long as\nDscho is happy.\n[1] https://wiki.debian.org/RpathIssue\n-- \nbrian m. carlson: Houston, Texas, US\nOpenPGP: https://keybase.io/bk2204\n"},{"id":"377157","messageId":"13c40b4b819f702a52f7039177579f87fa90aa50.camel@mad-scientist.net","threadId":"51290","inReplyTo":"nycvar.QRO.7.76.6.1906130914250.42@tvgsbejvaqbjf.bet","subject":"Re: Reducing git size by building libgit.so","fromName":"Paul Smith","fromEmail":"paul@mad-scientist.net","sentAt":"2019-06-13T17:28:10Z","receivedAt":"2019-06-13T17:28:16Z","isPatch":false,"sender":{"key":"paul@mad-scientist.net","avatar":"https://avatars.githubusercontent.com/u/109636?v=4"},"body":"On Thu, 2019-06-13 at 09:51 +0200, Johannes Schindelin wrote:\n> Hassles aside, you mentioned Linux and macOS. What about literally\n> *all* the other platforms we support? Like AIX, NonStop, HP/UX, etc?\n\nI assumed that we were discussing providing an _option_ of building\nwith shared libraries, rather than removing support for static\nlibraries and only supporting shared libraries.  The former is the\ntypical model in portable projects.\n\nSo, the answer to most of the (important) issues you and Brian raise\nis, \"if it doesn't work, can't be made to work, is too slow, or is\nannoying for ANY other reason, then don't do it\".\n\nRegarding things like publish-ability of the API, I don't know what\nelse to say.  It's FOSS, after all: anyone can do whatever they want\n(with respect to building and using the code) regardless of the desires\nof the development team.  All you can do is make clear that the intent\nis that the API is not stable, and if they don't listen and their stuff\nbreaks, well, as the saying goes, they get to keep both halves.  Not\nadding any header files to the installation rules and packages is also\nhelpful :).\n\nThere's a certain amount of cold, hard reality that every FOSS project,\nregardless of how friendly and welcoming they aspire to be, simply\ncan't avoid while still making progress (and staying sane).\n\n\nI certainly don't want to minimize the amount of work involved here,\nnor do I want to in any way volunteer myself to undertake any of it: as\nI said, I don't have strong feelings about it.\n\nI'm just saying, there's no technical reason it can't be done while\nmaintaining the same features (such as relocatability) as the static\nlibrary installs, at least on the major platforms.\n\nCheers!\n\n"},{"id":"377169","messageId":"xmqq1rzxwdi6.fsf@gitster-ct.c.googlers.com","threadId":"51290","inReplyTo":"13c40b4b819f702a52f7039177579f87fa90aa50.camel@mad-scientist.net","subject":"Re: Reducing git size by building libgit.so","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-06-13T18:23:29Z","receivedAt":"2019-06-13T18:23:39Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Paul Smith <paul@mad-scientist.net> writes:\n\n> I assumed that we were discussing providing an _option_ of building\n> with shared libraries, rather than removing support for static\n> libraries and only supporting shared libraries.  The former is the\n> typical model in portable projects.\n> ...\n> So, the answer to most of the (important) issues you and Brian raise\n> is, \"if it doesn't work, can't be made to work, is too slow, or is\n> annoying for ANY other reason, then don't do it\".\n>\n> Regarding things like publish-ability of the API, I don't know what\n> else to say.  It's FOSS, after all: anyone can do whatever they want\n> (with respect to building and using the code) regardless of the desires\n> of the development team.  All you can do is make clear that the intent\n> is that the API is not stable, and if they don't listen and their stuff\n> breaks, well, as the saying goes, they get to keep both halves.  Not\n> adding any header files to the installation rules and packages is also\n> helpful :).\n>\n> There's a certain amount of cold, hard reality that every FOSS project,\n> regardless of how friendly and welcoming they aspire to be, simply\n> can't avoid while still making progress (and staying sane).\n>\n>\n> I certainly don't want to minimize the amount of work involved here,\n> nor do I want to in any way volunteer myself to undertake any of it: as\n> I said, I don't have strong feelings about it.\n>\n> I'm just saying, there's no technical reason it can't be done while\n> maintaining the same features (such as relocatability) as the static\n> library installs, at least on the major platforms.\n>\n> Cheers!\n"},{"id":"377180","messageId":"e37e5429-d66a-4cad-93b0-0dd849d4ce5c@kdbg.org","threadId":"51290","inReplyTo":"20190612233142.GC8616@genre.crustytoothpaste.net","subject":"Re: Reducing git size by building libgit.so","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2019-06-13T19:19:27Z","receivedAt":"2019-06-13T19:19:33Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 13.06.19 um 01:31 schrieb brian m. carlson:\n> [0] AFAIUI, Windows doesn't have RPATH-like functionality, and from what\n> I've read, the same-directory behavior may be going away due to security\n> concerns.  I don't use Windows, so any solution there is fine as long as\n> Dscho is happy.\n\nThe solution is NOT to use DLLs on Windows. They are touchy and slow.\n\n-- Hannes\n"}]}