Building (customised) on modern Debian

Hello everyone,

I want to build a installer that will contain my additions to gcrypt and ksba and gpgsm. I’m building tag 4.2.0 from github mirror.

I haven’t found any sort of tutorial for building on Debian that’s not 5 years old anywhere. Is that still the official procedure, to build on Wheezy? If it is, I can build in a VM.

The components I modified I removed from download lists, and I generate the source archives, package file with right checksums from my script so download.sh just considers them cached. I presume this is a good way to insert your own additions for non-production and testing purposes.

Sounds like a good start to just put your modified packages into the packages folder.

The “official” documentation how to build this is the README file in gpg4win. You can even use docker on any system to build it. Otherwise it is documented for Fedora, Debian and personally I also build it on SUSE Tumbleweed but i have not documented the requirements for that platform. The releases are always done on Debian stable.

Thank you for quick response :slight_smile:

I’m refering to README and got a Debian 10 up and running. There are some trivial issues in README (flex and bison need to be dependencies and ImageMagick rules need to be adapted for docs) but I also encountered a build issue with Kleopatra, “erase is not a member of std” which seems like a compiler standard mismatch. I have 6.0.0-3 mingw environment and 8.3.0 compilers. Respective gcc “version 8.3-win32 20190406 (x86_64-w64-mingw32)” says it has experimental C++20 support. And before that there was a libboost version mismatch so I had to pull 1.74 from backports too.

So I think I still didn’t nail down the build environment correctly.

If anyone has tips how to resolve this, or correct way to set up the environment on any distro, that would be very helpful. Meanwhile I’ll take a look into modifiying Docker definition to take my custom changes in.

Oh, I see the problem in the meantime we are on Debian 11 but since we updated our installation we did not update the README for an installation from scratch. And since you checked out the 4.2.0 repo the documentation about Docker and probably even the docker scripts are missing.

From what you want to do I would recommend docker: README · gpg4win

Would that be an option for you? To use gpg4win/master (which means you basically will have to remove all your downloaded packages and download them again and replace them with your own versions). Then it would just be:

./autogen.sh
./docker/build-gpg4win-docker-image.sh
./docker/run-gpg4win-build.sh

Great. I can try both Debian 11 and Docker approach. Thank you very much :slight_smile:

The Docker approach works.

But I have problems with integrating my code.
Can you please answer, or move to appropriate topic, the question on how gpg4win interacts with libgcrypt, ksba and gnupg source archives? There’s not a trace of these in playground directory. The build log only shows them in download phase.

The resulting installer does install a libgcrypt DLL on windows machine but it’s not “my” libgcrypt. I’m not sure where it comes from.

Sorry I should have read in more detail what you were trying to do in the first place. I only read “trying to build Gpg4win” but you are right, the source packages we download for libgcrypt and libksba are only used for the appimage. For Windows we use the binary GnuPG installer that is available from gnupg.org/downloads for security reasons as this is compiled on a different system with a different compiler etc.

While there is a way to build a custom GnuPG installer, this is also heavily automated and its hard to inject your own versions there. The starting point for that is in the GnuPG repo build-aux/speedo.mk

But you are likely better of to if you are developing your versions to compile them individually. For that you clone the repo: libgpg-error libksba and libgcrypt. And then in each of them you can call:

./autogen.sh && mkdir build && cd build && …/autogen.sh --build-w32 && make && make install which will install them under ~/w32root from there you can copy them onto your system.

Btw. why don’t you just put your patches in the upstream tracker of dev.gnupg.org there might be also better assistance there.

1 Like

Thanks for the recommendation, it’s ok to build a couple of DLLs individually to try out the windows solution. The patches are meant to be pushed upstream, they’re not “private”, but as my goal is Windows CMS/SMIME I need to test it beforehand.