From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) by sourceware.org (Postfix) with ESMTPS id 33B863858D35 for ; Thu, 3 Feb 2022 16:11:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 33B863858D35 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pl1-x629.google.com with SMTP id c3so2545766pls.5 for ; Thu, 03 Feb 2022 08:11:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to:content-transfer-encoding; bh=/+v6av06YD+OLvdo+eOZ7rp+dPNfTgUQW29avV3NYNc=; b=jm8DSVqR8kQ3UuuXswlGAcdse4P1iLO5ZqdpUyd6rAHVFjSjVWWxiouLvB7oaDmE4p OCF3lz25jKbxo7E9ElOX6b3XFOswtF4fc5CqRR35NLV29wPkdzjlOlkoLlPEyxTIpZPy KJnzSMtROhWMa64CCA7tq9QYd2rNnGqbxnEQira53jj43elo2/ZCW2QxAGGczH5JwY0X JyzsXNvIplD9eb1YtckNK/Fdckgd7ak56q4t9Q3D06rkf6leWCqBYmxeOFOmZTamPkFa HZhqbp9jP9OHSVX/jras16z0mM6RQkHNgBNaeWgHTGxIG8BIuCLCKxFrYYD/2lzDkOX3 sIuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=/+v6av06YD+OLvdo+eOZ7rp+dPNfTgUQW29avV3NYNc=; b=KsLtTHysqng6FRBpZAubLptosFCfKkXga+EIo2MSJ3w4gy0mtEN1Brc/3JUWARGvYB wbiRYiktvipofVkAAVKiZ6X1q1LwRuT2ucI2rSye2rIwuMbmItMuLDzK0woN6WGYKN1L FtENQtfHKHO5k4cR4zFnbYtSPaCh9MYciGYn8c5js47rQROwApHE4gSsdxCE3Haf8iuH 4BcKCKwbi4y7zDjlsZWQ0FHec6pK9pZfGhfi1cTpSXcEDKuoOO+KTAVhABPYBBmxRy5w DNq84eF/g2HLkrT67w237KNLsURlNsQ43JNscX/vavJffeAvwmWZsw8xcNrcWqIp78Y5 YHfg== X-Gm-Message-State: AOAM532+lHNYJrCwKr0SA/1EWmYZBMU7dX741wKd16AtmlIZC3AJ71vN PgFjykWlHUrNnMgJSdFd5ZUf81Ac+foP7w== X-Google-Smtp-Source: ABdhPJwW8C7OkqZwPJMjzbjhKTpwngUkchM5YlJZ06GQSJJjQq507gWLoPl5eIZDZ+N2EN43SOyAJw== X-Received: by 2002:a17:90b:1d06:: with SMTP id on6mr14755865pjb.6.1643904714041; Thu, 03 Feb 2022 08:11:54 -0800 (PST) Received: from [192.168.0.23] (65-130-12-252.slkc.qwest.net. [65.130.12.252]) by smtp.gmail.com with ESMTPSA id ha21sm10237480pjb.48.2022.02.03.08.11.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 03 Feb 2022 08:11:53 -0800 (PST) Message-ID: Date: Thu, 3 Feb 2022 09:11:51 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.5.1 Subject: Re: libgloss multilib installs broken [was nds broken by recent patches] Content-Language: en-US To: newlib@sourceware.org, Mike Frysinger References: <171dc9cb-6b2c-ead3-1c55-27fadb33220f@gmail.com> <3da42247-9096-0a03-4b38-66460854c2c7@gmail.com> From: Jeff Law In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: Thu, 03 Feb 2022 16:11:57 -0000 I must have tested the wrong thing as bfin-elf isn't working yet.  It doesn't help that I'm only looking at this for a few minutes before my workday starts...    At least now I  know what's going on. The *build* is fine, things go south at *install* time. bfin has a wide variety of multilibs and we're installing them into the wrong directories. So I'm sitting in my build directory... > [jlaw@dl360p newlib]$ find . -name libsim.a > ./bfin-elf/libgloss/bfin/libsim.a > ./bfin-elf/bf532-none/libgloss/bfin/libsim.a > ./bfin-elf/bf532-none/mid-shared-library/libgloss/bfin/libsim.a > ./bfin-elf/bf532-none/mid-shared-library/mleaf-id-shared-library/libgloss/bfin/libsim.a > ./bfin-elf/bf532-none/msep-data/libgloss/bfin/libsim.a > ./bfin-elf/bf532-none/mfdpic/libgloss/bfin/libsim.a > ./bfin-elf/mid-shared-library/libgloss/bfin/libsim.a > ./bfin-elf/mid-shared-library/mleaf-id-shared-library/libgloss/bfin/libsim.a > ./bfin-elf/msep-data/libgloss/bfin/libsim.a > ./bfin-elf/mfdpic/libgloss/bfin/libsim.a As expected.  Now if I go into my install directory: > find . -name libsim.a > ./bfin-elf/lib/libsim.a Egad.  It looks like they all got installed on top of each other in the wrong directory, effectively ignoring the multilib subdirectories.  A checksum quickly shows the version in the install directory is actually this one from the build directory: > ./bfin-elf/bf532-none/mid-shared-library/mleaf-id-shared-library/libgloss/bfin/libsim.a If I go look at the Makefile in the terminal directory it has this: > # Multilib support variables. > # TOP is used instead of MULTI{BUILD,SRC}TOP. > MULTIDIRS = > MULTISUBDIR = [ ... ] > install-sim: >         ${mkinstalldirs} ${DESTDIR}${tooldir}/lib${MULTISUBDIR} >         for x in ${SIM_CRT0} ${SIM_BSP} ${SIM_SCRIPTS}; do \ >          ${INSTALL_DATA} $$x > $(DESTDIR)${tooldir}/lib${MULTISUBDIR}/$$x || exit $$?; \ >         done So, yea, no surprise that it installed into the wrong directory. I think this is the culprit patch: > commit 754f8def0dfeeb43afa5a96ad1971fd0ef02c419 > Author: Mike Frysinger > Date:   Sun Jan 23 01:10:33 2022 -0500 > >     libgloss: merge stub arch configure scripts up a level > >     For about half the ports, we don't need a subdir configure script. >     They're using the config/default.m[ht] rules, and they aren't doing >     any unique configure tests, so they exist just to pass top-level >     settings down to create the arch Makefile.  We can just as easily >     do that from the top-level Mkaefile directly and skip configure. > >     Most of the remaining configure scripts could be migrated up to >     the top-level too, but that would require care in each subdir. >     So let's be lazy and put that off to another day.