I close this bug as wontfix. If you can provide the requested changes for libtool please re-open this bug.

I merely said, that we won't replace libtool by the upstream version because that lacks other important changes we need. Upstream was not willing to integrate our changes for Windows support and also introduced a lot of other regressions as well as dropping support for some platforms. Thus we need to maintain our version.

I know exactly what you mean, but werner disagrees so that's not going to happen.

Forgive me. I was biting my tongue.

No response.

Maybe ask on a mailing list for help to find out why your environment is broken.

I tried on a fresh installation of Ubuntu 14.04.5 and could not reproduce the problem. Apparentlcy your test suite tries to link against an installed version of the library, which is very odd.

Can you provide a patch for our version of the libtool macros that only adds support for illumos?

libgpg-error is a placeholder project for the master version of our libtool, but all other packages are likely to be affected as well.

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