Bug or other problem with the toolchain (compiler, etc)
May 16 2022
May 13 2022
May 10 2022
Pushed the changes for http.c.
May 9 2022
GCC 11.3 and GCC 12.1 are out with the fix.
Mar 30 2022
Last part is applied. Let me consider how to solve, for other parts.
Mar 22 2022
I guess I don't understand what you mean by "native building". This build was with MinGW, which is as "native" as MinGW64 is.
The reason for the problem is (AFAIU) that MinGW64 went after Microsoft's change in stat due to the 32-bit vs 64-bit time and off_t values issue.s That change breaks backward compatibility in more than one way: programs compiled on some versions of Windows will not run on other versions. mingw.org's MinGW kept the original semantics and symbols, which is why _stat32 exists in the mingw.org's headers, but is not exposed by default.
Turned into a feature request because native building on Windows is not supported.
Mar 16 2022
Nov 23 2021
Oct 13 2021
Oct 12 2021
Bison used to be the de-facto standard yacc ;-)
I think that a simple way is defining a table (string -> token) by ourselves in yylex, not enabling %token-table.
(Then, we don't need to depend on the feature of string with %token, which is not supported by POSIX yacc.)
Oct 11 2021
Thanks for your findings. I recall that I read this in the announcement and cursed about this new tendency in GNU to break long standing APIs.
Looks like yytoknum was removed from Bison in version 3.8: http://git.savannah.gnu.org/cgit/bison.git/commit/?id=1efe31185ff6b0bc22ff527098971bedf1ace5f4
Sep 22 2021
Sep 1 2021
Based on GCC bugzilla, affected released GCC versions are 11.1 and 11.2.
(ab | ba) >= 0 is used to make optimization analysis for compiler more difficult. I see that with (ab | ba) == 0, it would be much easier for compiler to conclude than loop could exit early as soon as first a[i] != b[i] is seen.
Aug 31 2021
May 11 2021
Apr 18 2021
t-link does not do antthing useful, anyway. I don't think it is justified to add dlopen stuff. Running real test is anyway a manual action; for a full test automation we would need to emulate all supported cards.
Apr 17 2021
the t-link test should dlopen scute.so in runtime rather than link against it in build-time.
Apr 16 2021
As of slibtool commit 9c5ba5eb, scute now builds out of the box. I'd still recommend taking the above into consideration, though.
For what it's worth, scute is in violation of gnu libtool's documentation. Building with gnu libtool:
Apr 15 2021
Done for gpa.
Done for pinentry.
Apr 13 2021
Mar 29 2021
Sorry to dig up an old thread...
Feb 22 2021
The configure run tells you what libraries are missing - none in your case. However, something is wrong with your development setup: The configure run detected libksba but cc compiler did not found it anymore. Check that you don't have any special envvars set etc. What is the actual compiler command which failed (make sure not to pass V=0 to make for this).
Feb 21 2021
Feb 15 2021
Thanks, I try to keep the README always up to date with the debian depenencies as I find this useful myself without running configure multiple times to find all the dependencies.
Feb 14 2021
No question a list like this is bound to be incomplete, but the argument "the README can only tell about those which we don't expect to be installed on a developer's box" does not seem to apply to the other items already on the list. For instance build-essentials and automake are almost certainly on every developers machine already.
There is a message telling you what is missing. Thus I can not consider this a bug. There are just too many dependencies which are required for cross-compiling that the README can only tell about those which we don't expect to be installed on a developer's box.
Feb 12 2021
Feb 1 2021
no, that doesn't change anything.
Jan 31 2021
Does it build if configure with parameter 'ac_cv_sys_symbol_underscore=yes'? <path-to-libgcrypt-source>/configure ac_cv_sys_symbol_underscore=yes --host=aarch64-apple-darwin ...
Jan 30 2021
Compiling now works, but I get the following linker errors:
Jan 29 2021
Jan 28 2021
Jan 24 2021
Does attached patch help?
Jan 23 2021
I tried it - that doesn't help. Same error message.
Problem is in GET_DATA_POINTER macro. MacOS assembler expects data references in some different format than Linux. Could you try following edit and see if libgcrypt then compiles? In cipher/asm-common-aarch64.h, there is definition of GET_DATA_POINTER macro:
#ifdef _WIN32 #define GET_DATA_POINTER(reg, name) \ adrp reg, name ; \ add reg, reg, #:lo12:name ; #else #define GET_DATA_POINTER(reg, name) \ adrp reg, :got:name ; \ ldr reg, [reg, #:got_lo12:name] ; #endif
I have now tried to build libgcrypt 1.9.0 for arm64 using clang. I get the following error: