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.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jun 13 2016
Jun 8 2016
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.
Jun 6 2016
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.
Jun 4 2016
Jun 1 2016
Ian may have a different opinion on that (now) but the GNU build system defines
it in the way I described it.
May 27 2016
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.
Apr 26 2016
libgpg-error 1.22 is out with fix. Please test.
libgpg-error 1.2.2 is out. Please test with it.
Apr 15 2016
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.
Apr 14 2016
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.
Mar 8 2016
I have only been pulling from .tar.gz files.
I think that I fixed this issue in master. If you have time, please test, from
git repo.
Mar 2 2016
awk --version
GNU Awk 4.1.1, API: 1.1 (GNU MPFR 3.1.3, GNU MP 6.0.0)
Copyright (C) 1989, 1991-2014 Free Software Foundation.
Running the filter from the CLI: nothing happens.
root@/home/actionmystique/Program-Files/Ubuntu/GnuPG/git-libgpg-error# awk
'/^\"POT-Creation-Date:/&&!s{s=1;next};!/^#: /{print}'
^C
Ibraheem very kindly tested again. However, it is still not working completely.
He writes:
It's still core dumping... Out of curiosity, I explicitly defined
'USE_DOUBLE_FOR_ALIGNMENT 1' and the checks were passing on Solaris with no more
core dumps. I guess that means they're on the right track, just have to get the
preprocessor directives right for gcc and Solaris.
Full details are in
https://mail-index.netbsd.org/pkgsrc-users/2016/03/01/msg023078.html
Mar 1 2016
Running from the command line with gawk and mawk, I don't get an error message.
What version of awk are you using? Does this occur when triggering this from
the command line or only when running it from smartgit?
Thank you for clarification. I didn't know that pkgsrc supports other
platforms. Now, I understand.
The intention is that USE_DOUBLE_FOR_ALIGNMENT for Solaris 32-bit version.
I thought that checking ILP32 worked (but not, in fact). I believe that LP64
checking works (at least with GCC).
Feb 29 2016
I'm working on pkgsrc, which is a portable packaging system origination on
NetBSD. I myself work mostly on NetBSD.
However, we have patches for non-NetBSD platforms in pkgsrc, and this patch was
worked on by the two people mentioned earlier. Since I can not test on Solaris,
I asked them to test on Solaris, and Ibraheem did that.
I hope that clears it up.
Let me clarify/confirm. Does it work on Solaris? And now do you speak for NetBSD?
My fix is specific to Solaris (no matter if it's Sparc or not). It doesn't
handle any issues for NetBSD.
I seems that Sparc GNU/Linux doesn't have this alignment issue, but (for me) it
is highly likely that sparc architecutre requires the alignment of 8-byte.
Feb 27 2016
Thank you for the patch.
I don't have the environment, but I asked the original reporter to test.
Sadly, his reply is negative, see:
https://mail-index.netbsd.org/pkgsrc-users/2016/02/27/msg023071.html
Feb 26 2016
Thank you for your report. Yes, it is the alignment issue.
Please test.
Feb 15 2016
Thanks for debugging this. An alternative for your patch would be to use
es_fileno_unlocked but your idea is also fine.
Feb 3 2016
I think that we could add -lrt in configure script.
Solaris also has a problem for lock object.
Its pthread_mutex_t seems have alignment of 8-byte.
In posix-lock-obj.h, we will have a padding after vers and the union u.
So, it fails at assert (!"sizeof lock obj");
Reference:
http://src.illumos.org/source/xref/illumos-gate/usr/src/uts/common/sys/types.h
Dec 27 2015
due to pth-2.0.7/bin not being added to PATH
Nov 11 2015
Nov 7 2015
Sep 15 2015
Sep 11 2015
Aug 30 2015
Maybe add configure parameter to ignore subarch for 99% of cases in which it
does not matter? This will avoid patching in most of the cases.
Yes.
I doubt that the subarch always uses the same ABI.
Aug 29 2015
Thanks, but I do not understand the comment, do you suggest to patch this file
with every subarch out there? I still trying to understand why subarch is
important for the processing, it is a generic string.
Aug 26 2015
FWIW, meanwhile there is a mapping table in src/mkheader.c:canon_host_triplet.
Did you had a chance to test the patch or 1.19?
May 15 2015
The main page at bugs.gnupg.org explains that you should ask for updating your
role. I have done that now.
Duplicate of T1931
May 13 2015
Apr 10 2015
This has already been fixed in the repo:
commit c01c8f0c4f55d76b037c7f6aa44ad25ede18d38a
1.19 will soon be released.
Apr 9 2015
Apr 4 2015
Mar 24 2015
Can you please apply the attached patch which should help to get a more precise
error message. It might also be useful to show the file
src/lock-obj-pub.native.h
which is created int the build directory.
Mar 22 2015
Mar 10 2015
Please build libgcrypt directly and read README(cross-compiling).
I assume you are using libgpg-error 1.18, right?
So what? This is a wrapper for malloc thus it calles malloc with the args given
by the user.
No c+p of warnings please! Use gnupg-devel for such things.
No c+p of warnings please! Use gnupg-devel for such things.
No c+p of warnings please! Use gnupg-devel for such things.
Please STOP posting all warnings you see to the bugtracker. Use gnupg-devel is
you have questions. Thanks.