From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) by sourceware.org (Postfix) with ESMTPS id 7FC8B3861001 for ; Tue, 9 Mar 2021 19:12:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 7FC8B3861001 Received: by mail-ot1-x331.google.com with SMTP id t16so13908070ott.3 for ; Tue, 09 Mar 2021 11:12:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=R76Y5ed/8hCPtj+IU+hBiK9iTn66s3f9Psc8aYNnHk8=; b=spUP7eGrhrbYgQAfeNsCecscMFdq0El0NmNFwqvFPaI+n5j2x6eoXJWN4aVzn63Zuu cZ6rXxMGdbNlmNZ7P9fyXt3KEGR4jSQ1o4RxKqQm3eLeoSAcxV+ISkr57yuMCsl2MeVy 3oX0bFndQGb8/aAA1yYymqpdJcYgVX6/46wFvN9aPSUOYtt+CUbTNr80zmLRKmPfa1KK pyFPlXLpNCd7M4HjMrWJHysEz6UBja2c5m6TaLw5cO0HOlbqybvVi3H/lOivBR/jP32g srXud+VyXdBuo42+Zu2ks7lSEkH/t6pw/EAU+2CS75Br7JqmbLSfvQMh2FJaZXasilw0 pkTQ== X-Gm-Message-State: AOAM531cb+3sFJeDSswUzXuaGKZWDrEuImGgw6+E7s5aEu8ygCJuiWQx ASMnI6IBd2MuI0tDan9pTG94X+czLlPnraURnQIxmjhXsMU= X-Google-Smtp-Source: ABdhPJxZtSeZHiAjPa7IxkCrmYttEGb9XAW+A0XUUsXs3Od8JPAhDHLROOeV0GKPwohUgt+9bCYPSBXAIUj0mGhW0lg= X-Received: by 2002:a9d:3b86:: with SMTP id k6mr24969918otc.194.1615317119886; Tue, 09 Mar 2021 11:11:59 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: David Macek Date: Tue, 9 Mar 2021 20:11:47 +0100 Message-ID: Subject: Re: [PATCH] libc: Replace i386/sys/fenv.h symlink with an #include shim To: newlib@sourceware.org, David Macek Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_ENVFROM_END_DIGIT, 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: newlib@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Newlib mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2021 19:12:01 -0000 On Mon, Mar 8, 2021 at 11:00 AM Corinna Vinschen wrote: > This doesn't work. The machine-specific header will get installed to > $DESTDIR/usr/include/sys/fenv.h, and it will now include a non-existing > file. We have to keep the symlink or to duplicate the file. How come the newlib/libm/machine/i386/fenv.c non-symlink works? Is it installed differently? Coincidentally, is newlib/libc/machine/ft32/stpcmp.S file correct? > However, I'm not aware that we still support a development platform not > supporting symlinks. Even WIndows supports them for ages now. In the commit, I only mentioned "proper" symlink support for brevity, but there's a lot in that word. The differences are summarized for example in https://github.com/git-for-windows/git/wiki/Symbolic-Links#background. Due to these incompatibilities, if we want to handle symlinks on Windows we only have bad options. MSYS2 is keeping its traditional approach of making copies instead of symlinks (which could probably be re-evaluated) and that leads to the extraction issue described. Git for Windows seems to just create regular text files containing the link path by default. Multiple programs I use just skip the symlink when extracting. Microsoft's build of bsdtar (and probably Cygwin with winsymlinks:native) extracts a symlink successfully, but then it's fixed as a file symlink. None of the three other Cygwin's methods (default, .lnk, WSL symlink) are compatible with regular Win32 programs IIRC. I think by now you can see why I'm leaning towards not using symlinks unless unavoidable or portability is out of question. -- David Macek