From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12olkn2040.outbound.protection.outlook.com [40.92.22.40]) by sourceware.org (Postfix) with ESMTPS id 95D9E385800A for ; Fri, 25 Jun 2021 14:34:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 95D9E385800A ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SIzhUlLVqtKf+gmLPRk5qDh+1fLk5NW/znO6I7sQEzfrxpv093Z+PJP8+59UmsCTUqJhM+HAvzwrLDZ4qctSIB5YePY7+JQjodMjShZjjijAAS+hHarSzNFHdUaaZx6oWDMgNMqapUBg8YBQw3zbDYcETKfGHoUXkBW7esY8ceqhF0ett4p12EfJ9WGCxe+ZQPYEA4yxUKCudAQayprfBg+OoSm2nu+R7S8hsjXKZEh4cjMENxhbTIF6SltU/cN2WqUA62Cgd9VwPxJ3C13L8jCRfTct5dnYVfrXpwXYHDHJFi56aNsNIGvjX/1QItQrZCxNYfn+5gqVrqgEZDAeXA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GiQkArJvRQPhwK0W1pBwoEseOwniifna1+C4wKtcZDY=; b=kdFXR+Z5mR5kAO22T5whykxaMqmYJ8OGTmSMJ2gS9Cd1ZGRpqzE5lP/Ef/mbctGPwGaEIf1XAefJVjzv0Ab4dbozI1Krnw4mOT6NCgylS0zl5hJz1L52yeTbsUkF/iNVz1CfIbavmhGITAMUPS2TrsDZMHwn1BK/UhnnxSXFs1g1Uzb7oETb2/ebYtaQHinUBttm9llpi4yKAWcyy3xIQjX7UHlUZgsHBRgw+KO8OEDUaXwT+TjVEbxFCDo36+tS5pgLXCTVL9VvfRqgrB014J9Xx98SE6JP+nIvj+CWToQq7Cp6YBmpeMQetIXzi8368hUQI3JfrIz/7WHP/VfpvA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none Received: from SN6PR13MB4269.namprd13.prod.outlook.com (2603:10b6:805:e0::13) by SA0PR13MB3967.namprd13.prod.outlook.com (2603:10b6:806:9a::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4264.7; Fri, 25 Jun 2021 14:34:30 +0000 Received: from SN6PR13MB4269.namprd13.prod.outlook.com ([fe80::559b:6bdd:b5a5:2645]) by SN6PR13MB4269.namprd13.prod.outlook.com ([fe80::559b:6bdd:b5a5:2645%7]) with mapi id 15.20.4287.008; Fri, 25 Jun 2021 14:34:30 +0000 To: cygwin@cygwin.com From: Dietmar May Subject: libtool with mingw hangs building openocd in func_convert_core_msys_to_w32 Message-ID: Date: Fri, 25 Jun 2021 10:34:26 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-TMN: [Ch+q8JTnIHCkt0TOynhu7wsF2EMGVOCM] X-ClientProxiedBy: CH0PR03CA0285.namprd03.prod.outlook.com (2603:10b6:610:e6::20) To SN6PR13MB4269.namprd13.prod.outlook.com (2603:10b6:805:e0::13) X-Microsoft-Original-Message-ID: <355a97ed-2076-6756-8a5f-227e44537136@outlook.com> MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.20.200] (166.182.81.189) by CH0PR03CA0285.namprd03.prod.outlook.com (2603:10b6:610:e6::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4264.18 via Frontend Transport; Fri, 25 Jun 2021 14:34:29 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: b306f0c1-1d02-4eb9-6b4e-08d937e65793 X-MS-TrafficTypeDiagnostic: SA0PR13MB3967: X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: pEW4yyrFjtkYQRnG5xDlSeV9g2GtDbtUqwA8sOw5X+8/82fkH7K6pPaGtXmub2LhKVnHkisa5x4bpyM4wfo02iazmI7XWVjiu+BJ5uQ2gR2VMOB+V+THrBdz61ekiH3bXbQMFpk6GSsjBEjeevJhowZ0GA1E+Sf5IHRYr6c/bX/zSqAVYwdxhbBX874gTepfm/hqYCXWVi4cNndBP//g7LVS1AF9OH3kmWHPvyRLcDABoKUO+xlLVW1P9I3M1VHxKX4jOrcVk7zmSYnrmIJKBX42JqhRGg38YzzgCV8IOX5QES2nqZJF0C0GtboQxCnlbqkLgRjKKZohAsOG0ZoUEm1DoAoejsPKoR3veibEHPoSuJHxGV78j2zv3UMc7LzzZ2WP4OqUitGmyAG9cBBdWrvbk9KETFmO2dcZw1Jq7ssX1KFF4XTaZA9h1ACUaumqfoomoZ/99jzGjyhWJ90n5g== X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: MvMs1vU71paiEl3ZmnEj1GkwHDGCxnSloy4LrK6yMc24VgbPisyz4ncYJ7OgSdVkPmbR2e4Th0Y0jtFqaMVEfRLIO4OQZTQ1xF9haX37O43iLgZi8hHzgbxXGnwTnZ8pmd+XjPeuTcqAL2taF49vwg== X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b306f0c1-1d02-4eb9-6b4e-08d937e65793 X-MS-Exchange-CrossTenant-AuthSource: SN6PR13MB4269.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Jun 2021 14:34:30.4218 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR13MB3967 X-Spam-Status: No, score=1.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FORGED_MUA_MOZILLA, FREEMAIL_FROM, KAM_NUMSUBJECT, MSGID_FROM_MTA_HEADER, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Level: * 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, 25 Jun 2021 14:34:35 -0000 SUMMARY func_convert_core_msys_to_w32 in /usr/share/libtool/build-aux/ltmain.sh has an extraneous '/' in the call to ( cmd //c echo "$1" ) causing make to hang indefinitely when configured with --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 The project builds successfully on msys2 & mingw-w64-x86_64-gcc installed, as well as on git-for-windows-sdk (which uses msys2). msys2 has the same issue ('//c'), but the compiler is in the path, so no cross-compilation configuration is needed (and apparently this function is not invoked). DETAILS func_convert_core_msys_to_w32() in the generated libtool script, when configured using --build and --host for mingw, expands to: cmd //c echo ... | sed //c is not a valid option to cmd.exe, and causes cmd.exe to hang indefinitely. This is reproducible from the command line: cmd //c echo .libs/ | /usr/bin/sed -e 's/[ ]*$//' -e 's|\\\\*|\\|g;s|/|\\|g;s|\\|\\\\|g' ps aux shows cmd.exe, with sed at pid cmd.exe + 1. kill is the only way to terminate. By changing "cmd //c" to "cmd /c", the command completes successfully. /usr/share/libtool/build-aux/ltmain.sh is the template, which contains the code: # func_convert_core_msys_to_w32 ARG # Convert file name or path ARG from MSYS format to w32 format. Return # result in func_convert_core_msys_to_w32_result. func_convert_core_msys_to_w32 () {   $debug_cmd   # awkward: cmd appends spaces to result   func_convert_core_msys_to_w32_result=`( cmd //c echo "$1" ) 2>/dev/null` |     $SED -e 's/[ ]*$//' -e "$sed_naive_backslashify"` } #end: func_convert_core_msys_to_w32 I've been able to get past this problem by editing this file and running configure again. Unfortunately, make aborts at a later point with a different (but perhaps related?) error: func_to_tool_file src/.libs/libopenocd.libcmd func_convert_file_msys_to_w32 src/.libs/libopenocd.libcmd func_convert_core_msys_to_w32 src/.libs/libopenocd.libcmd func_convert_file_check src/.libs/libopenocd.libcmd src\\.libs\\libopenocd.libcmd func_execute_cmds $AR $AR_FLAGS $oldlib$oldobjs~$RANLIB $tool_oldlib exit $?  exit $?w_eval x86_64-w64-mingw32-ar cru src/.libs/libopenocd.a @src\\.libs\\libopenocd.libcmd func_quote_for_expand x86_64-w64-mingw32-ar cru src/.libs/libopenocd.a @src\\.libs\\libopenocd.libcmd func_notquiet x86_64-w64-mingw32-ar cru src/.libs/libopenocd.a @src\\.libs\\libopenocd.libcmd func_echo x86_64-w64-mingw32-ar cru src/.libs/libopenocd.a @src\\.libs\\libopenocd.libcmd libtool: link: x86_64-w64-mingw32-ar cru src/.libs/libopenocd.a @src\\.libs\\libopenocd.libcmd : No such file or directory\.libs\libopenocd.libcmd make[2]: *** [Makefile:2811: src/libopenocd.la] Error 1 The file *is* there: $ ls src/.libs libopenocd.lax  libopenocd.libcmd Running the command directly completes with no errors: $ x86_64-w64-mingw32-ar cru src/.libs/libopenocd.a @src\\.libs\\libopenocd.libcmd $ One thing I don't understand is why libtool is converting paths to windows format to run inside of a cygwin shell. The command completes successfully *if no path conversion occurs* - so why bother? $ x86_64-w64-mingw32-ar cru src/.libs/libopenocd.a @src/.libs/libopenocd.libcmd $ Is this a holdover from 13 year old mingw behavior? or related somehow to running autotools in a cmd.exe environment (like Microsoft's original NT "posix" subsystem, a port of gnu commands to run "natively" under cmd.exe)? Can libtool just ditch all of the back and forth path conversions, and simplify all of this? REPRODUCING Install mingw64-x86_64-gcc-g++, autoconf, autoconf2.1, autoconf2.5, automake and pkg-config in cygwin. I believe that will pull in all required dependencies. git clone https://git.code.sf.net/p/openocd/code cd openocd ./bootstrap ./configure --disable-werror --disable-doxygen-pdf --enable-ftdi --enable-jlink --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 make # or make -j8