From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) by sourceware.org (Postfix) with ESMTPS id 10E3C387085A for ; Fri, 26 Jun 2020 09:31:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 10E3C387085A Received: by mail-lf1-x12a.google.com with SMTP id t9so4783932lfl.5 for ; Fri, 26 Jun 2020 02:31:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=FxbDn18QoY+MQTLaa3/asH0ujxmNU9LKjKOi/CjTYQ8=; b=MNIHx3CBn9T+jtQdbRqMP1BwaQZLEtkCzK/p0onG2JPUgM+eBY+2GuPR4vkzj99eLw /MJtWuPEb2kuOIshLLsmhmpPfvVNs+3NB/bIlAEXMYNxvtRaAfP2AwidaIFDZhvz11sa XfLSjTGeSOTEIugvgzWTBpg9b+NmxqU4SqQbLl6FYVxwcxVAc9zUn2bqX40O+VPMJM8a WS24piFBLhHV8k3yIvG7YlDz9WPOIvlG3Kh/71sgj4uFGuRTNhMISwwludd1i1GhGfzW zqZGRIYyjeJsjkPXQNruHHis7aHVnGI2DggM+JNems14RbT0EazxmMo5vjrfnwmPbMaS ATKA== X-Gm-Message-State: AOAM5327pBm0rdP5SWO7vUEkNfo4lzlqclr9KFhQ7acyFcGP53zQfxS2 pEXEwxM9ChK+kjIHf4m4KrkL8Xdj X-Google-Smtp-Source: ABdhPJyc/SMZBAKVQR0nkQt/4xiszcFDhzyQtVKImIbe99+sTACX0xZCaNVfKymZpc/w3NhGMcrQ7Q== X-Received: by 2002:ac2:46f0:: with SMTP id q16mr1347955lfo.51.1593163902025; Fri, 26 Jun 2020 02:31:42 -0700 (PDT) Received: from JOKK (87-249-176-245.ljusnet.se. [87.249.176.245]) by smtp.gmail.com with ESMTPSA id m11sm789179ljj.122.2020.06.26.02.31.41 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Jun 2020 02:31:41 -0700 (PDT) From: To: Subject: Using cygwin-dll with msvc-exe Date: Fri, 26 Jun 2020 11:31:40 +0200 Message-ID: <00a401d64b9c$9958e6d0$cc0ab470$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdZLl6bBesD7XE+cQPuccKuiAd/XYA== Content-Language: en-gb X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham 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 09:32:01 -0000 Hi all Our task is to use an own cygwin-gcc-dll imported and used in a msvc-exe (64-bit-system) 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 ... 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