From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 36205 invoked by alias); 29 May 2017 15:11:04 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 36194 invoked by uid 89); 29 May 2017 15:11:03 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 spammy=sofa, zro, 8 X-HELO: smtp-out-no.shaw.ca Received: from smtp-out-no.shaw.ca (HELO smtp-out-no.shaw.ca) (64.59.134.9) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 29 May 2017 15:11:01 +0000 Received: from [192.168.1.100] ([174.0.238.184]) by shaw.ca with SMTP id FMJydRzybETFpFMJzd6AYZ; Mon, 29 May 2017 09:11:04 -0600 X-Authority-Analysis: v=2.2 cv=dZbw5Tfe c=1 sm=1 tr=0 a=WqCeCkldcEjBO3QZneQsCg==:117 a=WqCeCkldcEjBO3QZneQsCg==:17 a=IkcTkHD0fZMA:10 a=v1OfHkp4bXOIkeHmsTwA:9 a=QEXdDO2ut3YA:10 Reply-To: Brian.Inglis@SystematicSw.ab.ca Subject: Re: grep-3.0-2 issues within Makefile To: cygwin@cygwin.com References: <845061b7-fab9-33b8-d699-25c9ac07906f@redhat.com> From: Brian Inglis Message-ID: Date: Mon, 29 May 2017 17:16:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <845061b7-fab9-33b8-d699-25c9ac07906f@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfLD6lJSsBvF7x3eqCSqORA8MQceDfhsRWZRhYTjZkAdJMZdaXaVA9DXgfwYPVp8sV0GVaTgprYQK+6Az2UKk5+AAQjfqCez3TpTTvebrE4K3gxMogAQ7 +OIstvkDKVI9oaORdW2Q536J+53DI6Ub6ukGcTYTdip06m8yefDWj6ur8UwoQy4SwJpsNRN2XVnBlA== X-IsSubscribed: yes X-SW-Source: 2017-05/txt/msg00477.txt.bz2 On 2017-05-29 05:44, Eric Blake wrote: > On 05/29/2017 06:39 AM, Eric Blake wrote: >>>> localsyms: libtcctmp.o >>>> @$(READELF) $< -Ws | $(AWK) "{print \$$8}" | sort | uniq \ >> Most likely, $(READELF) is producing \r\n-terminated output. > That said, WHAT is $(READELF) actually expanding to? If it is the cygwin > binutils version, it should NOT be outputting \r\n in the first place. > Generally, you don't get \r\n output unless you are mixing non-cygwin > programs into the pipeline. Cygwin .o files are not ELF format and not recognized as such by readelf $ readelf src/astro/sofa/20160503_a/c/build/zr.o -Ws readelf: Error: Not an ELF file - it has the wrong magic bytes at the start or file $ file src/astro/sofa/20160503_a/c/build/zr.o src/astro/sofa/20160503_a/c/build/zr.o: data running Cygwin readelf on cross builds which produce ELF .o don't generate "\r": $ file util/*.o util/ntp-keygen.o: ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (SYSV), not stripped, with debug_info util/ntp-keygen-opts.o: ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (SYSV), not stripped, with debug_info util/ntptime.o: ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (SYSV), not stripped, with debug_info util/tickadj.o: ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (SYSV), not stripped, with debug_info util/version.o: ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (SYSV), not stripped, with debug_info $ readelf util/*.o -Ws | wc -lwcL 460 3479 26678 84 $ readelf util/*.o -Ws | grep $'\r' | wc -lwcL 0 0 0 0 and it's not the Cygwin mingw binutils $ /usr/bin/x86_64-w64-mingw32-readelf util/*.o -Ws | grep $'\r' | wc -lwcL 0 0 0 0 and just to prove this detects "\r" $ echo $'\r' | grep $'\r' | wc -lwcL 1 0 2 0 so culprit must be native Mingw binutils readelf. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple