Link of ONC RPC client fails with: undefined references
I have simple ONC RPC client and server that build on Ubuntu with rpcgen
"(Ubuntu GLIBC 2.31-0ubuntu9.7) 2.31" (under
"5.10.102.1-microsoft-standard-WSL2") but fails to build on Cygwin
("3.3.4(0.341/5/3) 2022-01-31 19:35 x86_64 Cygwin") with rpcgen "(rpcsvc-proto)
1.4".
Naively, it appears that Ubuntu has a much newer version (2.31) than Cygwin
(1.4). Is this the problem?
gzip'ed cygcheck output and the test program and makefile are attached.
Output of "make all"
Making RPC header file rpcgen_output/date.h from date.x
mkdir -p rpcgen_output/
rm -f rpcgen_output/date.h
rpcgen -h -o rpcgen_output/date.h date.x
Compiling objs/date_client.o from src/date_client.c
mkdir -p objs/
gcc -c -g -O0 -I ./rpcgen_output/ -oobjs/date_client.o src/date_client.c
Making RPC client stub rpcgen_output/date_clnt.c from date.x
mkdir -p rpcgen_output/
rm -f rpcgen_output/date_clnt.c
rpcgen -l -o rpcgen_output/date_clnt.c date.x
Compiling objs/date_clnt.o from rpcgen_output/date_clnt.c
mkdir -p objs/
gcc -c -g -O0 -I ./rpcgen_output/ -oobjs/date_clnt.o rpcgen_output/date_clnt.c
Making objs/date_client from objs/date_client.o objs/date_clnt.o
gcc -ltirpc -o objs/date_client objs/date_client.o objs/date_clnt.o
/usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld:
objs/date_client.o: in function `date_prog_1':
/home/BVoris/git/ONC-rpc-test/src/date_client.c:15: undefined reference to
`clnt_create'
/usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld:
/home/BVoris/git/ONC-rpc-test/src/date_client.c:17: undefined reference to
`clnt_pcreateerror'
/usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld:
/home/BVoris/git/ONC-rpc-test/src/date_client.c:33: undefined reference to
`clnt_perror'
/usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld:
objs/date_clnt.o:date_clnt.c:(.rdata$.refptr.xdr_wrapstring[.refptr.xdr_wrapstring]+0x0):
undefined reference to `xdr_wrapstring'
collect2: error: ld returned 1 exit status
make: *** [Makefile:53: objs/date_client] Error 1
Building the server also fails but with different errors. Output of "make
objs/date_server":
Compiling objs/date_server.o from src/date_server.c
mkdir -p objs/
gcc -c -g -O0 -I ./rpcgen_output/ -oobjs/date_server.o src/date_server.c
src/date_server.c: In function 'get_remote_date_1_svc':
src/date_server.c:34:30: warning: initialization of 'struct sockaddr_in *' from
incompatible pointer type 'struct sockaddr_in6 *' [-Wincompatible-pointer-types]
34 | struct sockaddr_in *sock = svc_getcaller(
| ^
Making RPC server code rpcgen_output/date_svc.c from date.x
mkdir -p rpcgen_output/
rm -f rpcgen_output/date_svc.c
rpcgen -s tcp -o rpcgen_output/date_svc.c date.x
Compiling objs/date_svc.o from rpcgen_output/date_svc.c
mkdir -p objs/
gcc -c -g -O0 -I ./rpcgen_output/ -oobjs/date_svc.o rpcgen_output/date_svc.c
Making objs/date_server from objs/date_server.o objs/date_svc.o
gcc -ltirpc -o objs/date_server objs/date_server.o objs/date_svc.o
/usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld:
objs/date_svc.o: in function `date_prog_1':
/home/BVoris/git/ONC-rpc-test/rpcgen_output/date_svc.c:31: undefined reference
to `svc_sendreply'
/usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld:
/home/BVoris/git/ONC-rpc-test/rpcgen_output/date_svc.c:41: undefined reference
to `svcerr_noproc'
/usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld:
/home/BVoris/git/ONC-rpc-test/rpcgen_output/date_svc.c:46: undefined reference
to `svcerr_decode'
/usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld:
/home/BVoris/git/ONC-rpc-test/rpcgen_output/date_svc.c:50: undefined reference
to `svc_sendreply'
/usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld:
/home/BVoris/git/ONC-rpc-test/rpcgen_output/date_svc.c:51: undefined reference
to `svcerr_systemerr'
/usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld:
objs/date_svc.o: in function `main':
/home/BVoris/git/ONC-rpc-test/rpcgen_output/date_svc.c:65: undefined reference
to `pmap_unset'
/usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld:
/home/BVoris/git/ONC-rpc-test/rpcgen_output/date_svc.c:67: undefined reference
to `svctcp_create'
/usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld:
/home/BVoris/git/ONC-rpc-test/rpcgen_output/date_svc.c:72: undefined reference
to `svc_register'
/usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld:
/home/BVoris/git/ONC-rpc-test/rpcgen_output/date_svc.c:77: undefined reference
to `svc_run'
/usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld:
objs/date_svc.o:date_svc.c:(.rdata$.refptr.xdr_wrapstring[.refptr.xdr_wrapstring]+0x0):
undefined reference to `xdr_wrapstring'
/usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld:
objs/date_svc.o:date_svc.c:(.rdata$.refptr.xdr_void[.refptr.xdr_void]+0x0):
cygdll 3.3.4 breaks cygpath.exe. mistyped commands result in fork bomb
I had to revert to 3.3.3-1 to restore functionality.with 3.3.4 invoking cygpath would cause an Access Violation Exception (0x05) and kill the thread so that I couldn't even do a 'cygpath --help' All of a sudden I also am experiencing fork bombs if I type an invalid command. eg. type 'l' instead of 'ls' and ENTER, it spawns hundreds of 'bash.exe' processes. A half dozen 'pkill -9 bash.exe' heads off calamity. "In the information society, nobody thinks. We expected to banish paper, but we actually banished thought.” -- Michael Crichton, Jurassic Park “Ours may become the first civilization destroyed, not by the power of our enemies, but by the ignorance of our teachers and the dangerous nonsense they are teaching our children. In an age of artificial intelligence, they are creating artificial stupidity.' - Thomas Sowell cygcheck.out Description: Binary data -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Reach Professionals
Hi, Can I send you a taster of one of our email lists? We run email lists based on your requirements. If you could send me your target audience, Industries: Titles: Geography: Any other specifications: I'll come up with the data counts other details & I'd be happy to send over few taster for your review. Regards, Stacy Styles To edit mail preference, reply with Exclude in the Theme Line. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: GNU make losing jobserver tokens
On Apr 29 00:01, Takashi Yano wrote:
> On Thu, 28 Apr 2022 16:09:24 +0200
> Corinna Vinschen wrote:
> > On Apr 28 09:42, Ken Brown wrote:
> > > On 4/27/2022 10:13 AM, Takashi Yano wrote:
> > > > On Fri, 1 Apr 2022 17:45:51 +0900
> > > > Takashi Yano wrote:
> > > > > [...]
> > > > > diff --git a/winsup/cygwin/sigproc.cc b/winsup/cygwin/sigproc.cc
> > > > > index 62df96652..3824af199 100644
> > > > > --- a/winsup/cygwin/sigproc.cc
> > > > > +++ b/winsup/cygwin/sigproc.cc
> > > > > @@ -1325,6 +1325,10 @@ wait_sig (VOID *)
> > > > > _sig_tls = &_my_tls;
> > > > > bool sig_held = false;
> > > > > + /* Wait for _main_tls initialization. */
> > > > > + while (!cygwin_finished_initializing)
> > > > > +Sleep (10);
> > > > > +
> > > > > sigproc_printf ("entering ReadFile loop, my_readsig %p,
> > > > > my_sendsig %p",
> > > > > my_readsig, my_sendsig);
> > > > >
> > > > > I guess _main_tls may not be initialized correctly until
> > > > > cygwin_finished_initializing is set.
> > > > >
> > > > > Any comments would be appreciated.
> > >
> > > This seems reasonable to me.
>
> Thanks Ken and Corinna.
>
> > Missed that, sorry. I agree this seems reasonable, but wouldn't it be
> > cleaner if we *start* wait_sig only after cygwin_finished_initializing
> > is set to true?
>
> I also thought so, however, there is a comment in dcrt0.cc
> as follows. So, there seems to be some reason to start
> wait_sig before cygwin_finished_initialization.
>
> /* Initialize signal processing here, early, in the hopes that the creation
> of a thread early in the process will cause more predictability in memory
> layout for the main thread. */
> if (!dynamically_loaded)
> sigproc_init ();
This is a 32-bit only problem. The 64 bit address space layout is as
predictable as can be. Maybe the above fix should go into 3.3 and for
3.4 we try differently?
Corinna
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: GNU make losing jobserver tokens
On Thu, 28 Apr 2022 16:09:24 +0200
Corinna Vinschen wrote:
> On Apr 28 09:42, Ken Brown wrote:
> > On 4/27/2022 10:13 AM, Takashi Yano wrote:
> > > On Fri, 1 Apr 2022 17:45:51 +0900
> > > Takashi Yano wrote:
> > > > I have tried to reproduce the issue by building OpenJDK
> > > > from source, however, I could not.
> > > >
> > > > Instead, I encountered another issue.
> > > >
> > > > Building OpenJDK sometimes (rarely) failed with error such as:
> > > >
> > > >0 [sig] make 5484 sig_send: error sending signal 11, pid 5484,
> > > > pipe handle 0x118, nb 0, packsize 176, Win32 error 0
> > > > 124917 [main] make 5484 sig_send: error sending signal -72, pid 5484,
> > > > pipe handle 0x118, nb 0, packsize 176, Win32 error 0
> > > > common/modules/GensrcModuleInfo.gmk:77: *** open:
> > > > /home/yano/jdk/build/windows-x86-server-release/make-support/vardeps/make/common/modules/GensrcModuleInfo.gmk/jdk.accessibility/ALL_MODULES.vardeps:
> > > > No such file or directory. Stop.
> > > > make[2]: *** [make/Main.gmk:141: jdk.accessibility-gensrc-moduleinfo]
> > > > Error 2
> > > > make[2]: *** Waiting for unfinished jobs
> > > >
> > > >
> > > > I looked into this new problem and found that wait_sig() thread
> > > > crashes with segfault. It seems that accessing _main_tls causes
> > > > access violation if a signal is sent just after the process is
> > > > started.
> > > >
> > > > static void WINAPI
> > > > wait_sig (VOID *)
> > > > {
> > > >[...]
> > > >if (!pack.mask)
> > > > {
> > > > tl_entry = cygheap->find_tls (_main_tls);
> > > > dummy_mask = _main_tls->sigmask; // <--- Segfault here
> > > > cygheap->unlock_tls (tl_entry);
> > > > pack.mask = _mask;
> > > > }
> > > >
> > > > I also found the following patch resolves the issue.
> > > >
> > > > diff --git a/winsup/cygwin/sigproc.cc b/winsup/cygwin/sigproc.cc
> > > > index 62df96652..3824af199 100644
> > > > --- a/winsup/cygwin/sigproc.cc
> > > > +++ b/winsup/cygwin/sigproc.cc
> > > > @@ -1325,6 +1325,10 @@ wait_sig (VOID *)
> > > > _sig_tls = &_my_tls;
> > > > bool sig_held = false;
> > > > + /* Wait for _main_tls initialization. */
> > > > + while (!cygwin_finished_initializing)
> > > > +Sleep (10);
> > > > +
> > > > sigproc_printf ("entering ReadFile loop, my_readsig %p, my_sendsig
> > > > %p",
> > > > my_readsig, my_sendsig);
> > > >
> > > > I guess _main_tls may not be initialized correctly until
> > > > cygwin_finished_initializing is set.
> > > >
> > > > Any comments would be appreciated.
> >
> > This seems reasonable to me.
Thanks Ken and Corinna.
> Missed that, sorry. I agree this seems reasonable, but wouldn't it be
> cleaner if we *start* wait_sig only after cygwin_finished_initializing
> is set to true?
I also thought so, however, there is a comment in dcrt0.cc
as follows. So, there seems to be some reason to start
wait_sig before cygwin_finished_initialization.
/* Initialize signal processing here, early, in the hopes that the creation
of a thread early in the process will cause more predictability in memory
layout for the main thread. */
if (!dynamically_loaded)
sigproc_init ();
--
Takashi Yano
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
FW: Postfix stable release 3.7.2 - interest in updated package?
I will prioritize the packaging of this release (see below) based on community interest, otherwise looking at late May. My task #10403 -Jason -Original Message- From: Wietse Venema Sent: Thursday, April 28, 2022 9:23 AM To: Postfix announce Cc: Postfix users Subject: Postfix stable release 3.7.2 [An on-line version of this announcement will be available at https://www.postfix.org/announcements/postfix-3.7.2.html] This reverts an overly complex change in the postscreen SMTP engine (made during Postfix 3.7 development), and replaces it with much simpler code. The bad change was crashing postscreen on some systems after receiving malformed input (for example, a TLS "hello" message). Workarounds are at the end of this text. Under conditions described below, the postscreen program attempted to read through an uninitialized 'const' pointer. The pointer value depended on the compiler type and compiler options, but crucially, it did not depend on network inputs. The conditions were that 1) postscreen was enabled (not the default), 2) SMTPUTF8 support was enabled (the default), and 3) postscreen received non-UTF8 input, for example, a TLS or RDP (remote desktop) handshake request. Depending on compiler details, the result of the read operation could be "uninteresting", a combined memory leak and file handle leak, or a postscreen crash with a segmentation violation (signal 11). The segmentation violation result was observed by Michael Grimm while running Postfix 3.7 and 3.8 on a FreeBSD 13.1 pre-release version, while the result was "uninteresting" with FreeBSD 13.0 (both systems use Clang instead of GCC). The result was also "uninteresting" on Fedora Linux with GCC, and on a few older systems with GCC. Workarounds: * Do nothing. On most systems the result is "uninteresting". * Do nothing. On systems where postscreen does crash, the crashes are rare, harmless, and postscreen restarts immediately when an SMTP client connects. On systems where postscreen does leak a file handle, it will restart when it reaches a resource limit. * Disable postscreen. Follow instructions in https://www.postfix.org/POSTSCREEN_README.html#turnoff You can find the updated Postfix source code at the mirrors listed at https://www.postfix.org/. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
[Attn: mercurial maintainer] hg fails with python3.9
/usr/bin/hg specifies /usr/bin/python3 in its shebang, but further down it has
libdir = '../lib/python3.8/site-packages'
This causes hg to fail as follows if /usr/bin/python3 points to python3.9:
$ hg
Traceback (most recent call last):
File "/usr/lib/python3.8/site-packages/mercurial/policy.py", line 69, in
_importfrom
fakelocals[modname] = mod = getattr(pkg, modname)
File "/usr/lib/python3.8/site-packages/mercurial/pycompat.py", line 317, in w
return f(object, sysstr(name), *args)
AttributeError: module 'mercurial.cext' has no attribute 'parsers'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/bin/hg", line 61, in
dispatch.run()
File "/usr/lib/python3.9/importlib/util.py", line 245, in __getattribute__
self.__spec__.loader.exec_module(self)
File "", line 850, in exec_module
File "", line 228, in _call_with_frames_removed
File "/usr/lib/python3.8/site-packages/mercurial/dispatch.py", line 21, in
from .i18n import _
File "/usr/lib/python3.9/importlib/util.py", line 245, in __getattribute__
self.__spec__.loader.exec_module(self)
File "/usr/lib/python3.8/site-packages/mercurial/i18n.py", line 123, in
if _plain():
File "/usr/lib/python3.8/site-packages/mercurial/i18n.py", line 115, in _plain
b'HGPLAIN' not in encoding.environ
File "/usr/lib/python3.9/importlib/util.py", line 245, in __getattribute__
self.__spec__.loader.exec_module(self)
File "/usr/lib/python3.8/site-packages/mercurial/encoding.py", line 41, in
charencode = policy.importmod('charencode')
File "/usr/lib/python3.8/site-packages/mercurial/policy.py", line 116, in
importmod
mod = _importfrom(pn, mn)
File "/usr/lib/python3.8/site-packages/mercurial/policy.py", line 71, in
_importfrom
raise ImportError('cannot import name %s' % modname)
ImportError: cannot import name parsers
Ken
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: GNU make losing jobserver tokens
On Apr 28 09:42, Ken Brown wrote:
> On 4/27/2022 10:13 AM, Takashi Yano wrote:
> > On Fri, 1 Apr 2022 17:45:51 +0900
> > Takashi Yano wrote:
> > > I have tried to reproduce the issue by building OpenJDK
> > > from source, however, I could not.
> > >
> > > Instead, I encountered another issue.
> > >
> > > Building OpenJDK sometimes (rarely) failed with error such as:
> > >
> > >0 [sig] make 5484 sig_send: error sending signal 11, pid 5484,
> > > pipe handle 0x118, nb 0, packsize 176, Win32 error 0
> > > 124917 [main] make 5484 sig_send: error sending signal -72, pid 5484,
> > > pipe handle 0x118, nb 0, packsize 176, Win32 error 0
> > > common/modules/GensrcModuleInfo.gmk:77: *** open:
> > > /home/yano/jdk/build/windows-x86-server-release/make-support/vardeps/make/common/modules/GensrcModuleInfo.gmk/jdk.accessibility/ALL_MODULES.vardeps:
> > > No such file or directory. Stop.
> > > make[2]: *** [make/Main.gmk:141: jdk.accessibility-gensrc-moduleinfo]
> > > Error 2
> > > make[2]: *** Waiting for unfinished jobs
> > >
> > >
> > > I looked into this new problem and found that wait_sig() thread
> > > crashes with segfault. It seems that accessing _main_tls causes
> > > access violation if a signal is sent just after the process is
> > > started.
> > >
> > > static void WINAPI
> > > wait_sig (VOID *)
> > > {
> > >[...]
> > >if (!pack.mask)
> > > {
> > > tl_entry = cygheap->find_tls (_main_tls);
> > > dummy_mask = _main_tls->sigmask; // <--- Segfault here
> > > cygheap->unlock_tls (tl_entry);
> > > pack.mask = _mask;
> > > }
> > >
> > > I also found the following patch resolves the issue.
> > >
> > > diff --git a/winsup/cygwin/sigproc.cc b/winsup/cygwin/sigproc.cc
> > > index 62df96652..3824af199 100644
> > > --- a/winsup/cygwin/sigproc.cc
> > > +++ b/winsup/cygwin/sigproc.cc
> > > @@ -1325,6 +1325,10 @@ wait_sig (VOID *)
> > > _sig_tls = &_my_tls;
> > > bool sig_held = false;
> > > + /* Wait for _main_tls initialization. */
> > > + while (!cygwin_finished_initializing)
> > > +Sleep (10);
> > > +
> > > sigproc_printf ("entering ReadFile loop, my_readsig %p, my_sendsig
> > > %p",
> > > my_readsig, my_sendsig);
> > >
> > > I guess _main_tls may not be initialized correctly until
> > > cygwin_finished_initializing is set.
> > >
> > > Any comments would be appreciated.
>
> This seems reasonable to me.
Missed that, sorry. I agree this seems reasonable, but wouldn't it be
cleaner if we *start* wait_sig only after cygwin_finished_initializing
is set to true?
Corinna
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: [PATCH] Cygwin: Unconditionally require win32api >= 10.0.0
On Apr 27 21:35, Jon Turney wrote: > Unconditionally require win32api >= 10.0.0, and check for it at > configure time. > > Note that there remains a use of __MINGW64_VERSION_MAJOR in > pseudo-reloc.cc under !CYGWIN (since that file is shared with the > MinGW and MinGW64 runtimes). > --- > winsup/configure.ac | 9 + > winsup/cygwin/ntdll.h | 6 -- > winsup/cygwin/sec_auth.cc | 19 --- > winsup/cygwin/winlean.h | 5 - > 4 files changed, 9 insertions(+), 30 deletions(-) LGTM Thx, Corinna
Re: GNU make losing jobserver tokens
On 4/27/2022 10:13 AM, Takashi Yano wrote:
On Fri, 1 Apr 2022 17:45:51 +0900
Takashi Yano wrote:
I have tried to reproduce the issue by building OpenJDK
from source, however, I could not.
Instead, I encountered another issue.
Building OpenJDK sometimes (rarely) failed with error such as:
0 [sig] make 5484 sig_send: error sending signal 11, pid 5484, pipe
handle 0x118, nb 0, packsize 176, Win32 error 0
124917 [main] make 5484 sig_send: error sending signal -72, pid 5484, pipe
handle 0x118, nb 0, packsize 176, Win32 error 0
common/modules/GensrcModuleInfo.gmk:77: *** open:
/home/yano/jdk/build/windows-x86-server-release/make-support/vardeps/make/common/modules/GensrcModuleInfo.gmk/jdk.accessibility/ALL_MODULES.vardeps:
No such file or directory. Stop.
make[2]: *** [make/Main.gmk:141: jdk.accessibility-gensrc-moduleinfo] Error 2
make[2]: *** Waiting for unfinished jobs
I looked into this new problem and found that wait_sig() thread
crashes with segfault. It seems that accessing _main_tls causes
access violation if a signal is sent just after the process is
started.
static void WINAPI
wait_sig (VOID *)
{
[...]
if (!pack.mask)
{
tl_entry = cygheap->find_tls (_main_tls);
dummy_mask = _main_tls->sigmask; // <--- Segfault here
cygheap->unlock_tls (tl_entry);
pack.mask = _mask;
}
I also found the following patch resolves the issue.
diff --git a/winsup/cygwin/sigproc.cc b/winsup/cygwin/sigproc.cc
index 62df96652..3824af199 100644
--- a/winsup/cygwin/sigproc.cc
+++ b/winsup/cygwin/sigproc.cc
@@ -1325,6 +1325,10 @@ wait_sig (VOID *)
_sig_tls = &_my_tls;
bool sig_held = false;
+ /* Wait for _main_tls initialization. */
+ while (!cygwin_finished_initializing)
+Sleep (10);
+
sigproc_printf ("entering ReadFile loop, my_readsig %p, my_sendsig %p",
my_readsig, my_sendsig);
I guess _main_tls may not be initialized correctly until
cygwin_finished_initializing is set.
Any comments would be appreciated.
This seems reasonable to me.
Ken
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: [PATCH 0/2] Fix build with w32api 10.0.0
On 28/04/2022 01:29, Takashi Yano wrote: On Wed, 27 Apr 2022 11:30:44 +0200 Corinna Vinschen wrote: On Apr 12 18:32, Jon Turney via Cygwin-patches wrote: Jon Turney (2): Cygwin: Fix build with w32api 10.0.0 Cygwin: Fix typo KERB_S4U_LOGON_FLAG_IDENTITY -> IDENTIFY Ops LGTM, thanks, Corinna Shouldn't these patches be applied also to cygwin-3_3-branch? Yes, I guess so. My mistake that they weren't.
