On Mac OS X 10.5.8, PPC Leopard, it built with the patch, gpg-agent works.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Mon, Apr 1
Mar 27 2024
Thank you for your quick testing.
Mar 26 2024
I've reported the success to MacPorts. My test was performed on only one platform, Mac OS X 10.4.11 or "Tiger". Since there exists a problem with building recent version of GPGME testing on Mac OS X 10.5.8 or "Leopard" will have to wait a few days…
With the unified patch all works fine (again), even the test target succeeds!
Performing the patch manually the "port" (package) built and installed. Starting then gpg-agent worked too, killing it (with gpgconf) worked as well.
The patches looks too large to merge (than actually needed), and not enough/clean like not having detection of the system.
Mar 25 2024
Mar 24 2024
Mar 1 2024
Apply the change in: rPTH417abd56fd7b: Fix INSERT_EXPOSE_RWLOCK_API for musl C library.
Feb 29 2024
@gniibe Thank you very much! That works.
@thesamesam Thank you for the report.
This seems to have regressed musl support, per https://bugs.gentoo.org/925443.
Fixed in npth 1.7.
Feb 23 2024
The patch is part of 1.7 - please test and in case of problems feel free to re-open.
Jan 30 2024
After applying patch to nPth 1.6 no semaphore leaks detected. Tested with GnuPG-2.3.3.
There has been positive feedback from production environment as well.
Jan 29 2024
Jan 23 2024
Jan 22 2024
Jan 20 2024
Aug 4 2023
npth_t is untouched for Windows 64-bit.
Oct 5 2022
Sep 22 2022
Jul 22 2022
@gniibe Thanks!
In the repo, for all related software, it's done.
Note that versions since 2020-11-07 to 2021-07-03 have major problem with non-POSIX shell, which doesn't support $(..) construct.
Jul 18 2022
Thank you.
May 27 2022
May 10 2022
Mar 24 2022
Indeed, different versions of MinGW use different symbols to guard the declaration, and using those symbols in not future-proof enough, IME.
Removing the declaration is definitely the best solution.
Pushed the change removing the definition.
Mar 23 2022
In T5889#156302, @gniibe wrote:Considering again, I think that just removing the definition of the struct timespec in npth.h is the best approach, given the situation, it's been there for MINGW64 and it's now in original MinGW.
Considering again, I think that just removing the definition of the struct timespec in npth.h is the best approach, given the situation, it's been there for MINGW64 and it's now in original MinGW.
Thank you. I understand the situation by looking at mingwrt-5.4.2-mingw32-src.tar.xz.
Mar 22 2022
The version of MinGW is 5.4.x, the latest one. It is available from https://osdn.net/projects/mingw/releases.
MinGW64 is a fork of the above (original) MinGW. They have unfortunately diverged, thus the need to have these changes.
Jan 4 2022
Dec 23 2021
Dec 22 2021
Nov 10 2021
Also applied to gpgme.
Since there is no problem with libgpg-error 1.43, I applied it to other libraries: npth, libassuan, libksba, and ntbtls.
Nov 3 2021
Oct 20 2021
Thanks! I was able to compile the current source code of npth (1.7) (with gcc 7.1. and ldd (GNU libc) 2.3.2 ). The error error: unknown type name ‘pthread_rwlock_t’ didn't occour.
I have a little concern for glibc 2.34 (which has dummy libpthread and all is actually in libc).
Okay, any thing else missing in nPth?
Oct 19 2021
Hello @gniibe, you did the last work on nPTh. Would you be so kind and look into this?
Sep 27 2021
These are great news. Thank you!
Pushed the change to libgpg-error and libgcrypt (1.9 and master).
Let us see if there are any problem(s) for that, I will apply it to other libraries when it will be found no problem.
Thank you for the information.
For the record, I put the link to the email submitted:
https://lists.gnu.org/archive/html/libtool-patches/2020-06/msg00001.html
Sep 22 2021
Oh, you are right, it's not upstream. It's actually applied to Homebrew (https://brew.sh/) libtool formula which is where I originally got libtool.m4, see:
I see your point. I'd like to locate/identify where the change comes from.
I think that what you refer by "new libtool.m4" is actually macOS local change (I mean, not from libtool upstream, AFAIK).
Could you please point out the source of the change?
Sep 21 2021
That would work, however we might hit this issue with a new macOS release. Would it make more sense to update to what the new libtool.m4 is doing? Linker flags are the same, it only changes the way they detect macOS versions:
That does indeed not look like something which could introduce a regression.
I misunderstood as if we need to update libtool from upstream.
macOS has low priority for us and I do not want to risk any regression.
About merging our local changes.
We have our own changes for ltmain.sh and libtool.m4.
And update from automake 1.16:
It's better to update the set of files from libtool:
build-aux/ltmain.sh m4/libtool.m4 m4/ltoptions.m4 m4/ltsugar.m4 m4/ltversion.m4 m4/lt~obsolete.m4
Our libtool was 2.4.2 + Debian patches + our local changes.
Debian patches are:
https://salsa.debian.org/mckinstry/libtool/-/blob/debian/master/debian/patches/link_all_deplibs.patch
https://salsa.debian.org/mckinstry/libtool/-/blob/debian/master/debian/patches/netbsdelf.patch
Aug 13 2021
Mar 17 2020
It is my confusion. The API is available. I only looked for symbols in the library.
It is #define-d macro to pthread_cond_*.
For Windows, it is available. I don't know the reason why it has not been available for POSIX.
Mar 16 2020
Mar 12 2020
May 15 2019
While I think that building with GCC 4 on Solaris 11/12 is minor issue, requirement of newer POSIX API (on GNU/Linux) would be a bit serious issue.
I pushed my change to fix this.
May 14 2019
While original npth-1.6 can be compiled with newer gcc (>= 5), we'd say please use CFLAGS+=-std=gnu99 with older gcc, as workaround.
I figured out:
- Removing -D_POSIX_C_SOURCE=200112L works both of gcc 4.9 and gcc 5.5 on Solaris 11.3 (even with -std=c99).
- Then, adding -D_XOPEN_SOURCE=500, gcc 4.9 works, but gcc 5.5 failed by another error (Compiler or options invalid for pre-UNIX 03 X/Open applications and pre-2001 POSIX applications)
- I confirmed gcc 5.5 defaults to -std=gnu99
Thanks for your offer. I have an account for GCC Compiler Farm. I'm trying with gcc211 machine. will back soon.
In case of gcc 4.8 on Solaris, could you please try this patch (instead of configure patch) to see if it works?
It looks like somewhat complicated more. It seems that specifying _POSIX_C_SOURCE=200112L is not good on Solaris with old GCC. Perhaps, it would have no problem with newer gcc (or -std=gnu99 option).
IIUC, -std=c99 won't solve this issue. It is Solaris specific C99 issue.
May 10 2019
It looks like Solaris only needs CFLAGS+=-std=c99. It was added for all programs and libraries listed at https://www.gnupg.org/download/index.html.
Feb 19 2019
Jan 23 2019
Jan 17 2019
OK, it's a libc with no pthread_rwlock_t.