Mailing List Archive

On Wed, Dec 5, 2018 at 4:31 PM Peter Lebbing <peter@digitalbrains.com> wrote:
>
> On 05/12/2018 12:35, Alon Bar-Lev wrote:
> > If you have, how many tweaks have you needed in order to make this
> > work?
>
> It sounds like /you/ have tried it. If it's not too much work, can you
> give an indication of the tweaks /you/ needed to build the current
> master branch?

It is only a matter of cost shift from single upstream to multiple
people and downstream. You can look at the Gentoo packages to see the
current tweaks, which are not working for all cases. We will see what
it takes to support cross-compile in the next versions. I hope the
cross compile and multilib (apart and together) will be tested and
supported before release.

I fully understand the response I got. No reason to continue this thread.

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

Hello Alon.

Am Mittwoch, den 05.12.2018, 13:35 +0200 schrieb Alon Bar-Lev:
> On Tue, Dec 4, 2018 at 11:57 PM Dirk Gottschalk
> <dirk.gottschalk1980@googlemail.com> wrote:
> > Hello Alon.

> > Am Dienstag, den 04.12.2018, 22:54 +0200 schrieb Alon Bar-Lev:
> > > On Tue, Dec 4, 2018 at 9:30 AM Werner Koch <wk@gnupg.org> wrote:
> > > > On Mon, 3 Dec 2018 00:31, alon.barlev@gmail.com said:
> > > >
> > > > > Please explain again why not give an option for downstream to
> > > > > build gnupg components using pkg-config, this does not take
> > > > > anything from whoever wishes to continue to use current mode.

> > I have no problem building the actual git snapshot of GPG only with
> > the installed libraries and header files from the system. So, what
> > are you complaining about? The .pc files which are not available in
> > your case?
> > Write them, if you want to link the libs with pkg-config for
> > configuration.

> > There is really no need of changing the build system at all. And
> > yes, it is autoconf. The scripts are a little complicated to read,
> > but it is autoconf, for sure, with some "extras".

> Just to make sure we are on the same page...
> Have you tried cross compile a complete solution of libraries? Have
> you tried cross-compile + multilib setup?

I compiled the libs for GnuPG on several platforms without any
problems. Usually I have the Systems which I compile for at least in a
virtual machine, so there is no need for cross compiling. But it should
work if the environment ist set up correctly, that I am sure of. There
is no program out there which cross compiles without any changes that
have to be made. On my fedora machine there are, for example, some
wrapper scripts if you want to cross compile for mingw which set up the
environment for configure, cmake and various other build systems.


> If you have, how many tweaks have you needed in order to make this
> work?

Even my own programs which are completely made with Autotools and
pkg-config need some tweaks if I want to cross compile them for
Windows, for example.

That's the reason why I prefer to compile on the target platform, this
makes life much easier. ^^

Regards,
Dirk

--
Dirk Gottschalk
Paulusstrasse 6-8
52064 Aachen, Germany

GPG: DDCB AF8E 0132 AA54 20AB B864 4081 0B18 1ED8 E838
Keybase.io: https://keybase.io/dgottschalk
GitHub: https://github.com/Dirk1980ac

Hello,

Dirk Gottschalk <dirk.gottschalk1980@googlemail.com> wrote:
> On my fedora machine there are, for example, some
> wrapper scripts if you want to cross compile for mingw which set up the
> environment for configure, cmake and various other build systems.

Right.

The questions are: how such a setup can be maintained, possibly cleanly.

Released versions of (old) GnuPG and GnuPG libraries require tweaks
which is GnuPG specific, by --with-<library-specific>-config options or
SYSROOT environment variable. From viewpoint of the current best
practice of cross build, I think, both could be considered not ideal,
because it is application specific, and the method uses command for
cross-target under cross-target directory, only works in a specific
use case, etc.

And... cross build is common these days. That's because mainly, it's
common that a system supports both of 32-bit and 64-bit environments.
Speaking about GNU systems, there are two different flavors, multiarch
support and multilib support. For example, the former uses
/lib/i386-linux-gnu and /lib/x86_64-linux-gnu, the latter uses /lib and
/lib64.

New version of GnuPG and GnuPG libraries, which is currently in master
branch, introduces new method, by a single script named gpgrt-config.
By this script, for building GnuPG, we don't need any application
specific tweaks any more. We can just supply --host=${HOST} to
configure invocation, which perfectly follows the current best practice
of cross build, I suppose.

It is unfortunate that we can't use pkg-config directly to achieve this
(yet). It still has an application specific script, that is,
gpgrt-config. But, no special tweak is required, because it is a script
which can be shared for all cross-targets, and it follows pkg-config
methodology (of using .pc files and its environment vars).

Perhaps, our changes are somewhat confusing. While we introduce new
method, we keep old method as well. So, old tweaks can still be valid
for both of old GnuPG and new GnuPG. And old tweaks by existing
software which use GnuPG libraries are still valid with new GnuPG
libraries.

I'm sorry to say that we don't accept further changes for old method in
GnuPG libraries. They keep staying there to keep supporting existing
software. Please use new method instead, for improving cross-build,
or use pkg-config directly.

I'm sorry if our .pc files brought an illusion like... the perfect
victory of pkg-config for GnuPG build. No, it's never our purpose, at
all.

I wish that our improvement makes cross-build easier for others, just
like it makes easier for us.


Happy Hacking,
--

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel