From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from forward100p.mail.yandex.net (forward100p.mail.yandex.net [77.88.28.100]) by sourceware.org (Postfix) with ESMTPS id E1936387084B for ; Fri, 26 Jun 2020 17:20:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org E1936387084B Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=yandex.ru Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=anrdaemon@yandex.ru Received: from forward102q.mail.yandex.net (forward102q.mail.yandex.net [IPv6:2a02:6b8:c0e:1ba:0:640:516:4e7d]) by forward100p.mail.yandex.net (Yandex) with ESMTP id D11D55981373; Fri, 26 Jun 2020 20:20:00 +0300 (MSK) Received: from mxback2q.mail.yandex.net (mxback2q.mail.yandex.net [IPv6:2a02:6b8:c0e:40:0:640:9c8c:4946]) by forward102q.mail.yandex.net (Yandex) with ESMTP id CBABB7F20015; Fri, 26 Jun 2020 20:20:00 +0300 (MSK) Received: from vla3-4c649d03f525.qloud-c.yandex.net (vla3-4c649d03f525.qloud-c.yandex.net [2a02:6b8:c15:2584:0:640:4c64:9d03]) by mxback2q.mail.yandex.net (mxback/Yandex) with ESMTP id mMncuCclvV-K0qawnNS; Fri, 26 Jun 2020 20:20:00 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1593192000; bh=FENXjHNrkjUlM3iV843MXYTJbl7Pn37LjG4SBet9c8U=; h=In-Reply-To:Subject:To:Reply-To:From:Message-ID:References:Date; b=OEw2E+tKbQhQvBx5COxVvJmAjIYevnAjlEnh/+3+I/RLDGQyHvbVGBGeL8iuB2UlL QVDjyDgtK79njIAg6+TRkrHWN5Y3pm1ReBBQ5lod3GqyOGjkMT9rN/KXZn16luGTl/ 6EEwMMvj7lI+7z1xjcRTZ9d99yZ7JVHfBmlLqnLo= Authentication-Results: mxback2q.mail.yandex.net; dkim=pass header.i=@yandex.ru Received: by vla3-4c649d03f525.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id 8C9FyMlyzY-K0leSU6S; Fri, 26 Jun 2020 20:20:00 +0300 (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (Client certificate not present) Received: from [192.168.1.10] (HELO daemon2.darkdragon.lan) by daemon2 (Office Mail Server 0.8.12 build 08053101) with SMTP; Fri, 26 Jun 2020 17:13:42 -0000 Date: Fri, 26 Jun 2020 20:13:42 +0300 From: Andrey Repin X-Mailer: The Bat! (v6.8.8) Home Reply-To: cygwin@cygwin.com X-Priority: 3 (Normal) Message-ID: <18310519099.20200626201342@yandex.ru> To: Kristian Ivarsson via Cygwin , cygwin@cygwin.com Subject: Re: Using cygwin-dll with msvc-exe In-Reply-To: <00a401d64b9c$9958e6d0$cc0ab470$@gmail.com> References: <00a401d64b9c$9958e6d0$cc0ab470$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_THEBAT, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: cygwin@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2020 17:20:05 -0000 Greetings, Kristian Ivarsson via Cygwin! > Our task is to use an own cygwin-gcc-dll imported and used in a msvc-exe > (64-bit-system) I may be wrong (I'm not a developer in this case), but there's an inherent problem with linking Cygwin DLL into native project. Cygwin uses wholly different memory layout than what you'd normally see in native apps. This is because Cygwin has to support POSIX-mandated fork(2) semantics. > According to https://cygwin.com/faq.html#faq.programming.msvc-gcc-objects it > seems like it would be possible by doing it like > https://cygwin.com/cygwin-ug-net/dll.html > The msvc-exe compiles and links with no problems, but crashes during start > up in runtime (as soon as there are any reference to the (extern "C") > functions in the DLL (they aren't even called)) > We're linking agains the import .lib and using implicit loading (i.e. no > LoadLibrary) > The console output is: > ... > $ /cygdrive/c/Repos/Trunk/Debug64/my_msvc_program.exe > 0 [main] my_msvc_program (17392) child_copy: cygheap read copy > failed, 0x180343408..0x18036E1D8, done 0, windows pid 17392, Win32 error 6 > 582 [main] my_msvc_program (17392) > C:\Repos\Trunk\Debug64\my_msvc_program.exe: *** fatal error - ccalloc would > have returned NULL > ... This is what happens when you mix different memory managers. > A snippet from strace output is: > ... > 193 5437 [main] my_msvc_program (12608) fhandler_pipe::create: > CreateFile: name \\.\pipe\cygwin-e022582115c10879-12608-sigwait > 198 5635 [main] my_msvc_program (12608) fhandler_pipe::create: pipe > write handle 0x130 > 171 5806 [main] my_msvc_program (12608) dll_crt0_0: finished > dll_crt0_0 initialization > --- Process 12608 thread 2084 created > 1050 6856 [sig] my_msvc_program (12608) wait_sig: entering ReadFile > loop, my_readsig 0x12C, my_sendsig 0x130 > --- Process 12608, exception c0000005 at 00000004a9e3b012 > ... > I guess I'm experiencing the same issue as > https://stackoverflow.com/questions/25787344/using-dll-compiled-with-cygwin- > inside-visual-studio-2010 (it is using explicit loading of the DLL though) > Just linking the dll works fine, but as soon as a symbol is referenced, it > seems like the linker/loader make things end up in a weird way. The only odd > thing I can see is that the loader (ldd) finds our dll before cygwin1.dll > and thus our own dll is loaded before cygwin.dll > So, should it be possible to use cygwin-gcc-built-dll:s in msvc-built-exe:s > (or msvc-built-dll:s) ? If so, does anyone have a qualified idea of what > might be missing/wrong in what we're doing ? > Best regards, > Kristian > -- > 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 -- With best regards, Andrey Repin Friday, June 26, 2020 19:54:36 Sorry for my terrible english...