Mailing List Archive

Jeff,

Not too surprising.

To get libgcrypt to build on Big Sur I had to create a pair of patches for MacPorts:

https://github.com/macports/macports-ports/tree/7c793c22a4315ee01ae92ed7104cea4d6def1036/devel/libgcrypt/files

> On Mar 23, 2021, at 10:45 AM, Jeffrey Walton via Gnupg-devel <gnupg-devel@gnupg.org> wrote:
>
> Hi Everyone,
>
> I'm having trouble connecting to bugs.gnupg.org. I'm going to send
> this report to the mailing list.
>
> libgcrypt 1.9.2 is having some trouble on Apple M1 hardware. Attached
> is config.log and the test results.
>
> The GCC compile farm has a M1 machine for testing. It is GCC304, on
> port 2409. Also see https://cfarm.tetaneutral.net/machines/list/.
>
> Jeff
> <libgcrypt-config.log.zip><libgcrypt-test-suite.log.zip>_______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel


Marius
--
Marius Schamschula

On Tue, 23 Mar 2021 10:53, Marius Schamschula said:

> https://github.com/macports/macports-ports/tree/7c793c22a4315ee01ae92ed7104cea4d6def1036/devel/libgcrypt/files

You should never ever patch configure - that is a generated file. So
this is just a temoporary kludge to make things build.


Salam-Shalom,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

On Wed, Mar 24, 2021 at 12:35 PM Werner Koch <wk@gnupg.org> wrote:
>
> On Tue, 23 Mar 2021 10:53, Marius Schamschula said:
>
> > https://github.com/macports/macports-ports/tree/7c793c22a4315ee01ae92ed7104cea4d6def1036/devel/libgcrypt/files
>
> You should never ever patch configure - that is a generated file. So
> this is just a temoporary kludge to make things build.

That's actually a fairly clean fix for the break-fix cycle in this circumstance.

The Apple M1's lack Libtool and Autotools, so they can't autoreconf if
configure.ac is touched.

Jeff

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

> On Mar 24, 2021, at 11:41 AM, Jeffrey Walton <noloader@gmail.com> wrote:
>
> On Wed, Mar 24, 2021 at 12:35 PM Werner Koch <wk@gnupg.org> wrote:
>>
>> On Tue, 23 Mar 2021 10:53, Marius Schamschula said:
>>
>>> https://github.com/macports/macports-ports/tree/7c793c22a4315ee01ae92ed7104cea4d6def1036/devel/libgcrypt/files
>>
>> You should never ever patch configure - that is a generated file. So
>> this is just a temoporary kludge to make things build.
>
> That's actually a fairly clean fix for the break-fix cycle in this circumstance.
>
> The Apple M1's lack Libtool and Autotools, so they can't autoreconf if
> configure.ac is touched.


Why do you believe libtool and the autotools don’t exist on M1 machines?

Indeed, Werner is correct: fixing the configure.ac file is the better approach.

However, with macOS Big Sur the number of projects with implicit declaration errors is so large, we often do the quick fix.

Marius
--
Marius Schamschula

On Wed, Mar 24, 2021 at 12:59 PM Marius Schamschula
<lists@schamschula.com> wrote:
>
>
> On Mar 24, 2021, at 11:41 AM, Jeffrey Walton <noloader@gmail.com> wrote:
>
> On Wed, Mar 24, 2021 at 12:35 PM Werner Koch <wk@gnupg.org> wrote:
>
>
> On Tue, 23 Mar 2021 10:53, Marius Schamschula said:
>
> https://github.com/macports/macports-ports/tree/7c793c22a4315ee01ae92ed7104cea4d6def1036/devel/libgcrypt/files
>
> You should never ever patch configure - that is a generated file. So
> this is just a temoporary kludge to make things build.
>
> That's actually a fairly clean fix for the break-fix cycle in this circumstance.
>
> The Apple M1's lack Libtool and Autotools, so they can't autoreconf if
> configure.ac is touched.
>
> Why do you believe libtool and the autotools don’t exist on M1 machines?

The one I bought did not have them. I had to install libtool myself:

% command -v autoconf
% command -v autoreconf
% command -v libtool
/usr/bin/libtool
% command -v glibtool
/usr/local/bin/glibtool

> Indeed, Werner is correct: fixing the configure.ac file is the better approach.

Until you have to autoreconf and the tools are missing or too old...

Jeff

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

On Mar 24, 2021, at 12:03 PM, Jeffrey Walton <noloader@gmail.com> wrote:
>
> On Wed, Mar 24, 2021 at 12:59 PM Marius Schamschula
> <lists@schamschula.com <mailto:lists@schamschula.com>> wrote:
>>
>>
>> On Mar 24, 2021, at 11:41 AM, Jeffrey Walton <noloader@gmail.com> wrote:
>>
>> On Wed, Mar 24, 2021 at 12:35 PM Werner Koch <wk@gnupg.org> wrote:
>>
>>
>> On Tue, 23 Mar 2021 10:53, Marius Schamschula said:
>>
>> https://github.com/macports/macports-ports/tree/7c793c22a4315ee01ae92ed7104cea4d6def1036/devel/libgcrypt/files
>>
>> You should never ever patch configure - that is a generated file. So
>> this is just a temoporary kludge to make things build.
>>
>> That's actually a fairly clean fix for the break-fix cycle in this circumstance.
>>
>> The Apple M1's lack Libtool and Autotools, so they can't autoreconf if
>> configure.ac is touched.
>>
>> Why do you believe libtool and the autotools don’t exist on M1 machines?
>
> The one I bought did not have them. I had to install libtool myself:
>
> % command -v autoconf
> % command -v autoreconf
> % command -v libtool
> /usr/bin/libtool
> % command -v glibtool
> /usr/local/bin/glibtool
>
>> Indeed, Werner is correct: fixing the configure.ac file is the better approach.
>
> Until you have to autoreconf and the tools are missing or too old…

Sure, libtool is part of Xcode.

Everything else is installed via MacPorts, Homebrew or Fink - or manually built.

Marius
--
Marius Schamschula

On Wed, Mar 24, 2021 at 1:09 PM Marius Schamschula
<lists@schamschula.com> wrote:
>
> On Mar 24, 2021, at 12:03 PM, Jeffrey Walton <noloader@gmail.com> wrote:
>
> On Wed, Mar 24, 2021 at 12:59 PM Marius Schamschula
> <lists@schamschula.com> wrote:
>
>
>
> On Mar 24, 2021, at 11:41 AM, Jeffrey Walton <noloader@gmail.com> wrote:
>
> On Wed, Mar 24, 2021 at 12:35 PM Werner Koch <wk@gnupg.org> wrote:
>
> On Tue, 23 Mar 2021 10:53, Marius Schamschula said:
>
> https://github.com/macports/macports-ports/tree/7c793c22a4315ee01ae92ed7104cea4d6def1036/devel/libgcrypt/files
>
> You should never ever patch configure - that is a generated file. So
> this is just a temoporary kludge to make things build.
>
> That's actually a fairly clean fix for the break-fix cycle in this circumstance.
>
> The Apple M1's lack Libtool and Autotools, so they can't autoreconf if
> configure.ac is touched.
>
> Why do you believe libtool and the autotools don’t exist on M1 machines?
>
> The one I bought did not have them. I had to install libtool myself:
>
> % command -v autoconf
> % command -v autoreconf
> % command -v libtool
> /usr/bin/libtool
> % command -v glibtool
> /usr/local/bin/glibtool
>
> Indeed, Werner is correct: fixing the configure.ac file is the better approach.
>
> Until you have to autoreconf and the tools are missing or too old…
>
> Sure, libtool is part of Xcode.
>
> Everything else is installed via MacPorts, Homebrew or Fink - or manually built.

This machine has Command Line Tools, not Xcode. (I don't have a
AppleId or developer account).

Jeff

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

> On Mar 24, 2021, at 12:15 PM, Jeffrey Walton <noloader@gmail.com> wrote:
>
> On Wed, Mar 24, 2021 at 1:09 PM Marius Schamschula
> <lists@schamschula.com <mailto:lists@schamschula.com>> wrote:
>>
>> On Mar 24, 2021, at 12:03 PM, Jeffrey Walton <noloader@gmail.com> wrote:
>>
>> On Wed, Mar 24, 2021 at 12:59 PM Marius Schamschula
>> <lists@schamschula.com> wrote:
>>
>>
>>
>> On Mar 24, 2021, at 11:41 AM, Jeffrey Walton <noloader@gmail.com> wrote:
>>
>> On Wed, Mar 24, 2021 at 12:35 PM Werner Koch <wk@gnupg.org> wrote:
>>
>> On Tue, 23 Mar 2021 10:53, Marius Schamschula said:
>>
>> https://github.com/macports/macports-ports/tree/7c793c22a4315ee01ae92ed7104cea4d6def1036/devel/libgcrypt/files
>>
>> You should never ever patch configure - that is a generated file. So
>> this is just a temoporary kludge to make things build.
>>
>> That's actually a fairly clean fix for the break-fix cycle in this circumstance.
>>
>> The Apple M1's lack Libtool and Autotools, so they can't autoreconf if
>> configure.ac is touched.
>>
>> Why do you believe libtool and the autotools don’t exist on M1 machines?
>>
>> The one I bought did not have them. I had to install libtool myself:
>>
>> % command -v autoconf
>> % command -v autoreconf
>> % command -v libtool
>> /usr/bin/libtool
>> % command -v glibtool
>> /usr/local/bin/glibtool
>>
>> Indeed, Werner is correct: fixing the configure.ac file is the better approach.
>>
>> Until you have to autoreconf and the tools are missing or too old…
>>
>> Sure, libtool is part of Xcode.
>>
>> Everything else is installed via MacPorts, Homebrew or Fink - or manually built.
>
> This machine has Command Line Tools, not Xcode. (I don't have a
> AppleId or developer account).

The CLT package installs alongside each version of Xcode. All the above mentioned packages should compile w/o the SDKs provided by Xcode.

Marius
--
Marius Schamschula

On Wed, Mar 24, 2021 at 1:27 PM Marius Schamschula
<lists@schamschula.com> wrote:
>
> On Mar 24, 2021, at 12:15 PM, Jeffrey Walton <noloader@gmail.com> wrote:
>
> On Wed, Mar 24, 2021 at 1:09 PM Marius Schamschula
> <lists@schamschula.com> wrote:
>
> On Mar 24, 2021, at 12:03 PM, Jeffrey Walton <noloader@gmail.com> wrote:
>
> On Wed, Mar 24, 2021 at 12:59 PM Marius Schamschula
> <lists@schamschula.com> wrote:
>
> On Mar 24, 2021, at 11:41 AM, Jeffrey Walton <noloader@gmail.com> wrote:
>
> On Wed, Mar 24, 2021 at 12:35 PM Werner Koch <wk@gnupg.org> wrote:
>
> On Tue, 23 Mar 2021 10:53, Marius Schamschula said:
>
> https://github.com/macports/macports-ports/tree/7c793c22a4315ee01ae92ed7104cea4d6def1036/devel/libgcrypt/files
>
> You should never ever patch configure - that is a generated file. So
> this is just a temoporary kludge to make things build.
>
> That's actually a fairly clean fix for the break-fix cycle in this circumstance.
>
> The Apple M1's lack Libtool and Autotools, so they can't autoreconf if
> configure.ac is touched.
>
> Why do you believe libtool and the autotools don’t exist on M1 machines?
>
> The one I bought did not have them. I had to install libtool myself:
>
> % command -v autoconf
> % command -v autoreconf
> % command -v libtool
> /usr/bin/libtool
> % command -v glibtool
> /usr/local/bin/glibtool
>
> Indeed, Werner is correct: fixing the configure.ac file is the better approach.
>
> Until you have to autoreconf and the tools are missing or too old…
>
> Sure, libtool is part of Xcode.
>
> Everything else is installed via MacPorts, Homebrew or Fink - or manually built.
>
> This machine has Command Line Tools, not Xcode. (I don't have a
> AppleId or developer account).
>
> The CLT package installs alongside each version of Xcode. All the above mentioned packages should compile w/o the SDKs provided by Xcode.

My M1 does not have Xcode. It only has CLT:

% find /Applications -name 'Xcode*'
% find /Library -name 'Xcode*'
% find /Library/Developer/CommandLineTools -name autoconf
% find /Library/Developer/CommandLineTools -name autoreconf
% find /Library/Developer/CommandLineTools -name libtool
/Library/Developer/CommandLineTools/usr/bin/libtool
% find /Library/Developer/CommandLineTools -name glibtool
%

CLT only provides a basic toolchain. The basic toolchain is all we
really need. Other tools folks might expect, like autoconf and
autoreconf, are not available.

And this issue is not limited to a new M1. If you stand up a Solaris
box the same problems apply because Autotools is too old. Or if you
regression test on CentOS 5, Ubuntu 4 or Fedora 1. If you have to
autoreconf then the build breaks.

That's why I said it was a fairly clean fix for the circumstance. The
configure patch avoids the autoreconf.

Jeff

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

On Wed, 24 Mar 2021 13:03, Jeffrey Walton said:

> Until you have to autoreconf and the tools are missing or too old...

In GnuPG project you should never do autoreconf. We distribute the
required files for running autoconf and automake. This way we get a
stable config system which is not suject to all the friction metween
different macro use.

Regarding M1, if you config.sub has stable support for it, we should
update these files and then see what other fixes are required. In
genera; autoconf generated configure scripts auto-adjust to a wide
variety of Unix systems and you only need to tweak things for some minor
cases - well, Apple is probably the worst player here.

Having said this, I just ask for some patience and until we support it.
Quick hacks are of course okay - it is free software. Unfortunately
they have a tendency to never go away and still show up in web searches
after years

Shalom-Salam,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

On Mar 24, 2021, at 1:17 PM, Werner Koch <wk@gnupg.org> wrote:
>
> On Wed, 24 Mar 2021 13:03, Jeffrey Walton said:
>
>> Until you have to autoreconf and the tools are missing or too old...
>
> In GnuPG project you should never do autoreconf. We distribute the
> required files for running autoconf and automake. This way we get a
> stable config system which is not suject to all the friction metween
> different macro use.
>
> Regarding M1, if you config.sub has stable support for it, we should
> update these files and then see what other fixes are required. In
> genera; autoconf generated configure scripts auto-adjust to a wide
> variety of Unix systems and you only need to tweak things for some minor
> cases - well, Apple is probably the worst player here.
>
> Having said this, I just ask for some patience and until we support it.
> Quick hacks are of course okay - it is free software. Unfortunately
> they have a tendency to never go away and still show up in web searches
> after years
>
> Shalom-Salam,
>
> Werner
>
> --
> Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

However, running autoreconf does make patching the configure script unnecessary.

In other words, the macros used to build the packaged configure script are outdated.

Marius
--
Marius Schamschula

On Wed, Mar 24, 2021 at 3:31 PM Marius Schamschula
<lists@schamschula.com> wrote:
>
> On Mar 24, 2021, at 1:17 PM, Werner Koch <wk@gnupg.org> wrote:
>
>
> On Wed, 24 Mar 2021 13:03, Jeffrey Walton said:
>
> Until you have to autoreconf and the tools are missing or too old...
>
> In GnuPG project you should never do autoreconf. We distribute the
> required files for running autoconf and automake. This way we get a
> stable config system which is not suject to all the friction metween
> different macro use.
>
> Regarding M1, if you config.sub has stable support for it, we should
> update these files and then see what other fixes are required. In
> genera; autoconf generated configure scripts auto-adjust to a wide
> variety of Unix systems and you only need to tweak things for some minor
> cases - well, Apple is probably the worst player here.
>
> Having said this, I just ask for some patience and until we support it.
> Quick hacks are of course okay - it is free software. Unfortunately
> they have a tendency to never go away and still show up in web searches
> after years
>
> However, running autoreconf does make patching the configure script unnecessary.
>
> In other words, the macros used to build the packaged configure script are outdated.

I find fetching the latest config.sub and confg.guess, and overwriting
the tarball's files, is good maintenance. In fact, if you are building
the tarballs, it is a good idea to do, too.

The Gnulib folks even recommend using the latest config.sub and
confg.guess by fetching them using Wget:
https://www.gnu.org/software/gettext/manual/html_node/config_002eguess.html.

Jeff

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

On Wed, 24 Mar 2021 23:16, Jeffrey Walton said:

> I find fetching the latest config.sub and confg.guess, and overwriting
> the tarball's files, is good maintenance. In fact, if you are building
> the tarballs, it is a good idea to do, too.

The problem with updating these files too often is that

- We need to do that for all GnuPG related packages so that we get the
same behavaiour.
- We had cases in the part were the updated version supported a new
platform but broke others.
- Bugs vanish are hide due to updates.

Thus I consider it better to wait some time for config.{guess,sub} to
stabilize before replacing them. Consider that GnuPG support more Unix
versions than just the common Linux distros and FreeBSD.


Salam-Shalom,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

On Tue, Mar 23, 2021 at 11:53 AM Marius Schamschula
<lists@schamschula.com> wrote:
>
> Not too surprising.
>
> To get libgcrypt to build on Big Sur I had to create a pair of patches for MacPorts:
>
> https://github.com/macports/macports-ports/tree/7c793c22a4315ee01ae92ed7104cea4d6def1036/devel/libgcrypt/files

Here's a couple of patches for the latest Apple hardware.

This is M1 specific:
https://github.com/noloader/Build-Scripts/blob/master/patch/libgcrypt-darwin.patch.
The patch fixes the missing symbols in libgcrypt and gnupg, and the
unaligned code warning. All of the self tests run ok after the patch.

This patch is for OS X 10.11 and above with SIP:
https://github.com/noloader/Build-Scripts/blob/master/patch/libgcrypt.patch
. I've been using it since Intel machines got SIP. It allows the self
tests to run without disabling SIP.

Jeff

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