From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10olkn2019.outbound.protection.outlook.com [40.92.40.19]) by sourceware.org (Postfix) with ESMTPS id C9F433890438 for ; Fri, 25 Jun 2021 20:46:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C9F433890438 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DShAUSiuFcj+KZBV9TVax9SxXkLuduvx9GP31XYHGpZiIV/4FVci/PUqIBl8/mVf+/aR8/jV7xGg4DHjc7epAtB0RYBWY6o466asCC1eftd/2ejzvnY3g0yvGvwF6sMzq48/RH9bfKyL5cmROxoh4Z2pG3DtB26mJd8dKMBee4plIoO+VBTj5DHnOJppiNH9lq4jSBo81J3YLhq9ZHAkPFOOHcf7gAoEucAPvk5x96RGGXz5BXNwiMuGu12n7ImSJvXIiACN4g3h7CbFYb41QaVlKRVeSUaxxCIpalJ668itSB988adng6akLNY5rxuGKYo8UDsfJjGlz1R7gNp7GA== 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=q/zEt7v01x2Scr4Z3ABj3IXFsjHtYtwl/jggn/VeyMI=; b=KSEcwDwLA44PgLLbwnjAqQySXZpHIXpREr0tBt+QRuL8qnoRM658wClRtSES1n2gZ21LWaHT/6dhsL8pacI5oJ+E2a9yIxjHNKX0eu+YsSW4kK8OTmJy1dzwdZfoxCH1rE7T3vZcieA+M9/q6S0yVJKQfVyHd/HAp9ES/cLDGR2LamH42+SGCwOdnGpWgoaWFAVO1taI+qJU7YxSIIfyKANlfEuToY2jWJ43CVXv3YqCyi6bLsnUH+hC+qrYRmcDtTIpYYAbz12Tarakl+TB4cVmg1GhsgYvmMlMDphxEK4gd/kMMLzdGS7LWHOb9J2fA0ckNFRrofyo9ly/FoDUVQ== 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 SN6PR13MB2446.namprd13.prod.outlook.com (2603:10b6:805:5f::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4287.13; Fri, 25 Jun 2021 20:46:36 +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 20:46:36 +0000 Subject: Re: libtool with mingw hangs building openocd in func_convert_core_msys_to_w32 From: Dietmar May To: cygwin@cygwin.com References: <355a97ed-2076-6756-8a5f-227e44537136@outlook.com> Message-ID: Date: Fri, 25 Jun 2021 16:46:31 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 In-Reply-To: <355a97ed-2076-6756-8a5f-227e44537136@outlook.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-TMN: [MSW0RT2w51Ry4GIshZoWkzywqpA1JdRuyUDfN5jVwLE=] X-ClientProxiedBy: CH2PR18CA0028.namprd18.prod.outlook.com (2603:10b6:610:4f::38) To SN6PR13MB4269.namprd13.prod.outlook.com (2603:10b6:805:e0::13) X-Microsoft-Original-Message-ID: <160185ab-c7f9-a563-7d4e-2c81130c54e2@outlook.com> MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.20.200] (166.182.254.188) by CH2PR18CA0028.namprd18.prod.outlook.com (2603:10b6:610:4f::38) 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 20:46:35 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 5a2f8c2c-d9db-4731-bf4b-08d9381a52d3 X-MS-TrafficTypeDiagnostic: SN6PR13MB2446: X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Mf+bym5nREqZb6MKJEEy2t2vrI5B40qCbGhuz59o76iIloQtoLtb5gkfLHCP1veKgIEpGWYNvdWdN3IDznQwUMPw1m2L/iCZn1QljRSZ0Knc0x6sOxFqkOPcit+3lgfDuzYPveAWL7FP0CC8izZP/oAhwUBTDoGOExW5yazIYTCyGJox7Y4k4GfnUoq3IK9YNMW7s/v5FZpYnq+NrlEQWU11KVShJIY95uIC4M0ePWU6xkEXbtRs+2iM0z3FmmHFgpT2cGmeSpLXBkomvHrwqIiqfAg81a7zqp7m8wwKpqMW1nT9r2ulDpVT4vbyYVOFqSk+QaWRC9X7A2pvsuYnPza0RbbI/mX+M6htNQIcLU3SfZbPEzxRbETWyX4LkDYdvWQ98Kc0XTeBDIbdZtZA3e/l1w58Ph+KWTVHYw3Ge9mj2h8bVtiNDs97tb47TlLs9scthtwooHvUfBhWMT0Rlw== X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: 6yrxC/C+GFN0PLQ65KpkoHzxcvu7gVvOKDLqCVd5c/2iZ7ZlE1mmZgxnNL58xUC91cE4K4VAaJVeQ82aNiuQv8SuUEcxEbEzfv2/jpQxaDoTqMK9vNsC7bYFEE7+8X4+ulx3s3aU7S7SPqUaRlfV9A== X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5a2f8c2c-d9db-4731-bf4b-08d9381a52d3 X-MS-Exchange-CrossTenant-AuthSource: SN6PR13MB4269.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Jun 2021 20:46:36.1818 (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: SN6PR13MB2446 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, NICE_REPLY_A, 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 20:46:38 -0000 The build completes successfully by replacing the "cmd /c | sed" construct with simply: func_convert_core_msys_to_w32_result=$1 so no path translation takes place. The function then becomes: func_convert_core_msys_to_w32 () {   $debug_cmd func_convert_core_msys_to_w32_result=$1 } > 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 > >