On Fri, Jan 26, 2024 at 10:55:21AM +0100, Patrick Steinhardt wrote: > On Fri, Jan 26, 2024 at 03:18:57AM -0500, Nikolaos Chatzikonstantinou wrote: > > On Thu, Jan 25, 2024 at 1:15 PM Daniel Kiper <dki...@net-space.pl> wrote: > > > > > > Adding Vladimir who knows GRUB history better than I... > > > > > > On Wed, Jan 24, 2024 at 01:23:55AM -0500, Nikolaos Chatzikonstantinou > > > wrote: > > > > > > [...] > > > > > > > My apologies for the repeated messages, but I came up with just one > > > > more question that I'm curious about. To summarize my questions: > > > > > > > > 1. Where is the libgcrypt bundle from grub from? I think my > > > > investigation has led me around version 1.7.0 of libgcrypt, but if I > > > > can get a precise commit or version, that would be useful. > > > > > > > > ... and now to my new question: > > > > > > Vladimir, could you help with that? > > > > > > > 2. What is the reason libgcrypt is bundled as opposed to a regular > > > > dependency? > > > > > > I am not entirely sure I understand the question. Could you elaborate? > > > > By bundling, I mean that someone copied libgcrypt files into the GRUB > > project. > > > > To elaborate further, regular programs (not like GRUB which is a > > bootloader) can link statically or dynamically to libraries; but also, > > there's a third option, to dump the source code of a library directly > > into the source tree of the project. To my understanding this third > > option (which is not really a third linker option as it is not related > > to the linker) is chosen when the project needs to include its own > > patch set to the library. I am curious if GRUB has patched libgcrypt > > for some reason, and is that why libgcrypt is bundled with GRUB? > > Yeah, the libgcrypt version carried by GRUB is heavily patched so that > it compiles within the non-libc environment that GRUB uses. That is the > whole crux of this topic -- if libgcrypt was simply a vanilla version > then it shouldn't be all that hard to update. > > I think in the long term it would be great indeed if we could refrain > from patching libgcrypt to the widest extent possible so that future > updates become easier. I guess that would require something of a "shim" > header that makes available all of the prerequisites that are currently > missing for libgcrypt to compile.
I concur! However, it would be nice to have simple mechanism which allow us to disable unused features. I am not sure it will be possible without patching libgcrypt heavily. Daniel _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel