On Nov 3 12:15, Christian Franke wrote: > Mark Geisert wrote: > > On 10/22/2024 7:45 AM, Corinna Vinschen wrote: > > > - create a new function like pthread_sigqueue_with_correct_prototype > > > (heh) > > > > > > - Add this function to cygwin.din as exported symbol > > > > > > - Add a matching entry to NEW_FUNCTIONS in Makefile.am, e.g., > > > > > > pthread_sigqueue=pthread_sigqueue_with_correct_prototype, > > > > > > - Implement either pthread_sigqueue_with_correct_prototype calling > > > pthread_sigqueue or vice versa, whatever makese more sense. > > > > I appreciate your redirecting me towards an acceptable solution. I've > > re-implemented the fix as you've indicated but there's one thing I > > cannot figure out. (BTW I implemented a new pthread_sigqueue_portable() > > calling existing pthread_sigqueue().) > > > > In cygwin/include/pthread.h, should both function names appear or just > > pthread_sigqueue? If the latter, which version of prototype? It seems > > problematic: We want the include file to have the new, portable, > > prototype for pthread_sigqueue() don't we? Doesn't that require that the > > original pthread_sigqueue() be renamed to something else and have it > > call the new pthread_sigqueue()? Maybe that changes one or more of the > > steps you wrote above? > > If backward compatibility with existing binaries using pthread_sigqueue() is > desired, I would suggest: > - Keep functionality and export symbol of the existing pthread_sigqueue(). > - Use a different export symbol for the new function. > - By default, map the pthread_sigqueue() call to the new symbol.
That's pretty much what I said above, I just tried to explain how to do that in Cygwin. > - Invent a #define that allows to use the old function. We don't need this. We only want backward compat to keep existing executables running. So we need The old and wrong pthread_sigqueue only as exported symbol. On recompiling the affected project, the bug hopefully shows up and can be easily fixed. Corinna