The platform is illumos, a fork of OpenSolaris.

No response.

and the platform is ...

The version of libtool that you ship does not have the necessary patches required to support my platform. Normally this isn't a problem because autogen.sh (or autoreconf) will update it.

You may not run your own version of libtool or libtoolize. Only the maintainer updates the autotools related files including libtool. This is to avoid bugs stemming from different or broken versions of autotools. This makes it much easier to reproduce bugs.

No reply to my question, thus it seems not to be important. Closing.
Note that replying to this will re-open the bug.

ping (see T2370 (wk on Nov 18 2016, 08:44 AM / Roundup))

What you describe is a standard requirement for many low level libraries and
tool when cross-compiling.

Please do not use the bug tracker for discussions but use gnupg-devel instead.
Thanks.

sorry, but it is not acceptable to copy executables via ssh to native computers
and execute them there and copy the result back to the build machine during
crosscompilation.
the whole arch-specific stuff is unnecessary when you just use pthread_mutex_t
directly and be done with it. patch attached.
in case there's a system that doesnt use pthreads, fine, then you can do the
arch-specific dance there, but please do not ruin the buildprocess for anyone
using a POSIX conforming system for this madness.

D399: 921_0001-fix-libgpg-error-lock-madness.patch

Sorry, this is not a bug but clearly documented in the README in the section
"Cross-Compiling". Your log shows that you are dojng just that:

checking whether we are cross compiling... yes

Please search the gnupg-devel ML for a discussion on why this is the Right Thing
to do for this library.

Yes, I have seen that URL but what I like to get an answer to my question here
or on gnupg-devel. I do not want to follow a possible long thread of some Linux
distribution.

There was a long drawn out discussion as to the validity of "-hardfloat" in the
triplet name. You can peruse at https://bugs.gentoo.org/show_bug.cgi?id=584052 .

I am not a dev and have pretty much given up. The Gentoo devs are adamant that this
is an upstream problem.

1.25 has been released.

ping

Distinguishing between 32 and 64 bit Windows in the same development package
works on Windows but only because 64 bit Windows also supports 32 bit Windows.
On most other platforms this is not the case. For a different ABI it is quite
common to require the installation of a platform specific development package.

You won't change the design to support sloppy build systems which would only
trigger hard to find bugs.

Fixed in 40e5ff0a0084c0d9521b401db4f38885bfdae233.

ping

This particular problem of assertion error, it was fixed in 1.22. So, I close this.
We also have T2378 for a possible change for Solaris/sparc. Please continue
there.

I believe that it's fixed in 1.22. Closing.

Closing, as I confirmed that -lrt is not needed any more in Solaris Userland
project:
https://hg.java.net/hg/solaris-userland~gate

IMHO, it's pretty uncommon from the packaging point of view to deliver
different generic header files for different platforms (one can meet
platform related ifdefs much often). It necessarily moves the platform
decision rules into the source code of the library consumer.

Yes, that is very likely the same bug. Feel free to reopen this report if yuo
can still reproduce it, in which case a backtrace would be very handy.

Fixed in 28fd0ab.

I can't find an explanation why gentoo inserts "-hardfloat". I doubt that this
is willy-nilly and as long as this has not been figured out, there is a
possibility of a different ABI and thus we can't simply alias it. Can you
please work with Kristian or someone else from gentoo to figure this out?

Thanks for binutils link.

Again, the host is not my invention. I linked it before and I'll do it again:
https://wiki.gentoo.org/wiki/Raspberry_Pi.

Gentoo's cross-compile tool, crossdev, suggests using "-hardfloat-" and "-
softfloat-" in the vendor field.

And here is how binutils handles this (they don't shy away from asterisks):
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=bfd/config.bfd

Is armv7a-hardfloat-linux-gnu guaranteed to be ABI compatible to some other arm
triplet? If that is the case, I suggest to either drop your(?) invention of
-hardfloat- or, better, to work with the config mainatiners to make sure it is
viewed as an alias.

How does binutils handle this triplet?

If you can describe the user base for that triplet, I may add an exception to
mkheader to get things done faster.

I'm sorry if your understanding of valid hostnames, acceptable by GNU projects, is
two decades old but this project happens to be the only one that assumes there
exists a finite list of valid hostnames without using pattern matching.

Using https://wiki.gentoo.org/wiki/Raspberry_Pi and a hostname of armv7a-
hardfloat-linux-gnu, with the notable exception of libgpg-error, I have been able
to compile and install all other GNU utilities included the core set of Gentoo
Linux, whether via the package's giving configure script or by use of autoreconf.

Hare are just a few of such GNU packages that I have personally been able to build
and install using the hostname "armv7a-hardfloat-linux-gnu":

coreutils-8.25
bash-4.3_p42
diffutils-3.3
findutils-4.6.0
grep-2.25
groff-1.22.3
gzip-1.8
tar-1.29
glibc-2.23
less-483
gawk-4.1.3
which-2.21
nettle-3.2
glibc-2.23
gcc-5.3.0
readline-6.3_p8
nano-2.5.3

The only other GNU package that doesn't compile for me is autogen. But that's due
to a lack of cross-compile support. It otherwise builds just fine natively on
armv7a-hardfloat-linux-gnu.

I would appreciate it if you could provide a specific GNU package using autotools
that you assert should fail to support such a hostname, other than this one, so
that I may provide a build log demonstrating that it indeed does.

1.23 has meanwhile been released.

Fixed with commit 7ed1502 for 1.23. I used your method.

What is smartgit? What OS are you using?

[gpg-error version seems to be 1.21]

Sorry, if _you_ want support for your _new target_ you should make sure that it
is supported by the GNU autotools which is used by a lot of software. This will
the soon be used by GnuPG etc.

It is entirely fine to point us new config versions with support for your
target. We will the update them in our packages - this is how we have done it
for close to 2 decades.

Re T2378 (jf on Jun 04 2016, 07:04 PM / Roundup): We consider a 32 bit and a 64 bit system different platforms and
thus you get different header files.

I applied your patch (commit 28fd0ab) and will do a new release soon.

Note: the comment 2) in T2378 (jf on Jun 04 2016, 07:04 PM / Roundup) [https://bugs.gnupg.org/gnupg/msg8416]
is not correct. The original text says:

1. • 8< ---
2. the fix updates only the external gpgrt_lock_t; it's internal

counterpart _gpgrt_lock_t is not updated. This causes that functions
working with the POSIX mutexes (gpgrt_lock_*()) could access misaligned
addresses - that results in Bus Errors on SPARC.

• 8< ---

The fact is that _gpgrt_lock_t already contains pthread_mutex_t thus it
is correctly aligned (alignes on 8B boundary). The problem pops up if
the outer gpgrt_lock_t is aligned on 4 bytes boundary, while the
internal _gpgrt_lock_t in aligned on 8 bytes.

Please, find below the preliminary suggested fix:

• ./src/gen-posix-lock-obj.c.orig Mon Jun 13 08:07:53 2016

+++ ./src/gen-posix-lock-obj.c Mon Jun 13 08:08:40 2016
@@ -42,21 +42,8 @@
#endif
#endif

-/* Special requirements for certain platforms. */

• define USE_LONG_DOUBLE_FOR_ALIGNMENT 0

-#if defined(sun) && !defined (LP64__) && !defined(_LP64)
-/* Solaris on 32-bit architecture. */

• define USE_DOUBLE_FOR_ALIGNMENT 1

-#else

• define USE_DOUBLE_FOR_ALIGNMENT 0

-#endif
-#if defined(hppa)

• define USE_16BYTE_ALIGNMENT 1

-#else

• define USE_16BYTE_ALIGNMENT 0

-#endif

-#if USE_16BYTE_ALIGNMENT && !HAVE_GCC_ATTRIBUTE_ALIGNED
+#if defined(hppa) && !HAVE_GCC_ATTRIBUTE_ALIGNED

1. error compiler is not able to enforce a 16 byte alignment #endif

@@ -122,12 +109,14 @@

"\n"
"#define GPGRT_LOCK_INITIALIZER {%d,{{",
SIZEOF_PTHREAD_MUTEX_T,

• if USE_16BYTE_ALIGNMENT

+/* Special requirements for certain platforms. */
+# ifdef (hppa)

"    int _x16_align __attribute__ ((aligned (16)));\n",

• • elif USE_DOUBLE_FOR_ALIGNMENT
• " double _xd_align;\n",
  • elif USE_LONG_DOUBLE_FOR_ALIGNMENT
• " long double _xld_align;\n",

+# elif defined(sun)
+ "#if (defined(sparc) || defined(sparc)) && \\\n"
+ " !defined (LP64) && !defined(_LP64)\n"
+ " double _xd_align;\n"
+ "#endif\n",

1. else "",
2. endif

I would except that config.sub already validates such names as 'armv7a-hardfloat-
linux-gnueabi' so there is nothing to fix. It is libgpg-error that doesn't. If
you feel it should invalidate such names please report that to the GNU config
folks instead. Their repo is at git://git.sv.gnu.org/config.git. Otherwise
pleases fix libgpg-error.

No, that is not acceptable for libgpg-error. Please report that to the GNU config
folks instead. Their repo is at git://git.sv.gnu.org/config.git

If you decide to change your mind, this patch places the logic in configure.ac.

D370: 845_libgpg-error-link-valid-header.patch

The host naming scheme accepted by this project is really just Debian oriented.
There is nothing saying you have to aid other distro's hostnames but I have yet to
witness a project more unfriendly to non-Debianesque distros that libgpg-error.
You don't have to accept the patch. Understandable, since mkheader would not
ideally be the way to go. But you should at least be open to the idea of
supporting the more liberal host naming schemes that other distros employ.

D375: 844_20_posix-lock-obj.patch

Ian may have a different opinion on that (now) but the GNU build system defines
it in the way I described it.

Whether or not config.sub is up to date should be irrelevant as to whether
libgpg-error should be able to handle CPU variants and the second field of a
HOST. It is supposed to be treated as a freeform field (see
http://airs.com/ian/configure/configure_4.html). As to the precision of the r.e,
it is not supposed to fix or mimic the logic of config.sub. It is to
effectively pigeonhole some HOST strings to a valid header file. Can you give me
a scenario where arm*linux-gnueabi shouldn't map to
lock-obj-pub.arm-unknown-linux-gnueabi.h?

Also, what is the source of your assertion that armv7a-hardfloat-linux-gnueabi
is not a valid canonical triplet? Everything that I have ever read about HOST
strings such as "armv7a-hardfloat-linux-gnueabi" is that configure scripts treat
them as valid and parse them with case statements (as demonstrated here
http://airs.com/ian/configure/configure_4.html). They don't demand that the
end-user pass a generic version of HOST, like "arm-unknown-linux-gnueabi". The
only reason I chose to patch mkheader.c instead or configure.ac was to build on
the mapping logic already there.

config.sub is indeed intended to canonicalize triplets. Thus a an up-to-date
config.sub should fix this. In any case you can always override the guessed
value like this:

  -/configure --build=$(build-aux/config.guess) --host=arm-unknown-linux-gnueabi

I fear that a single r.e. is not precise enough; config.sub has more complicated
rules.

libgpg-error 1.22 is out with fix. Please test.

libgpg-error 1.2.2 is out. Please test with it.

Thank you for your patch. Yes, we already located the issue is the alignment.
I think that it were good if the MTX were placed at the head. While your patch
works, it changes ABI of the lock object for existing archs, unfortunately.

I fixed the detection of Solaris in:
http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgpg-error.git;a=commit;h=f7a77c5c236ecec846de9be46703026f9b01008f

And I believe that the bug reported here had gone.
Please test current development master.

The attached is an analysis from the Solaris/SPARC point of view.

One of the possible SPARC specific fixes:

• ./src/posix-lock-obj.h.orig Wed Apr 13 08:24:20 2016

+++ ./src/posix-lock-obj.h Wed Apr 13 08:24:25 2016
@@ -29,7 +29,7 @@

typedef struct
{

• long vers;

+ long long vers;
#if USE_POSIX_THREADS

union {
  pthread_mutex_t mtx;

• ./src/gen-posix-lock-obj.c.orig Wed Apr 13 08:23:59 2016

+++ ./src/gen-posix-lock-obj.c Wed Apr 13 08:24:29 2016
@@ -66,7 +66,7 @@

int i;

#endif

struct {

• long vers;

+ long long vers;
#ifdef USE_POSIX_THREADS

pthread_mutex_t mtx;

#endif
@@ -105,7 +105,7 @@

   union and include a long and a pointer to a long.  */
printf ("typedef struct\n"
        "{\n"

• " long _vers;\n"

+ " long long _vers;\n"

"  union {\n"
"    volatile char _priv[%d];\n"
"%s"

@@ -138,7 +138,7 @@

printf ("/* Dummy object - no locking available.  */\n"
        "typedef struct\n"
        "{\n"

• " long _vers;\n"

+ " long long _vers;\n"

           "} gpgrt_lock_t;\n"
           "\n"
           "#define GPGRT_LOCK_INITIALIZER {%d}\n",

Note, that this was not fully tested on other platforms and might need
additional changes in the header files. I did some minor tests on
Solaris amd64/SPARCv9/SPARCv7, Linux amd64/SPARCv9.