From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x343.google.com (mail-wm1-x343.google.com [IPv6:2a00:1450:4864:20::343]) by sourceware.org (Postfix) with ESMTPS id 947123857C5A; Fri, 13 Nov 2020 11:22:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 947123857C5A Received: by mail-wm1-x343.google.com with SMTP id d142so7758885wmd.4; Fri, 13 Nov 2020 03:22:35 -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:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mcy+mAWgohYijzFX7qYuDpNIxqis5QzwRjg90hMoilw=; b=Eo8pQ5nlDz4hbz2TshSDDrqd3plnO2uwhqb4pW2rRuMLIysOTAWZn/dwzjb295HNHO ARMOT0GEgwkQ83ORRHDBqbMMj1NvTiuTNELdUWjE+g8gYqvFldEH88kzwNn8Z/afYE2f 6r9rfWte8EWS8xVyGCTMNyU3hkVvxfzsd0ffenr04PpAUqCtE2gC574gDD6nJi8q+4pe Rhp1RXG/BbbXXcPDhGzOO/OQiMwNxDepfLmSM+MR6z5aEeeBoWTXu3cGxDh0oh6ZZkhC gGF16SXjnDpFt6Cv1VhshjsBBUO5ImdbwGXiR/5R1c4q/fTv1o1k+cm63hmjtnsNveI7 Z8fw== X-Gm-Message-State: AOAM532wRvOZ07CKoKcbDB1ib96nJSmtFSrmAbNBIZcFXkdVl9RVHTHV 4E1wZVL0RkfikG3N4hee+/k= X-Google-Smtp-Source: ABdhPJzhAFXBI6HGmhgobkZMYCA21u+tgLVAKTlOCBbAqs4YZpnbUuElB7ulBqlCFCF2MS8axVoZGg== X-Received: by 2002:a05:600c:2285:: with SMTP id 5mr2029374wmf.149.1605266554576; Fri, 13 Nov 2020 03:22:34 -0800 (PST) Received: from [192.168.1.212] (host81-138-1-83.in-addr.btopenworld.com. [81.138.1.83]) by smtp.googlemail.com with ESMTPSA id y10sm10659916wru.94.2020.11.13.03.22.33 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Nov 2020 03:22:33 -0800 (PST) Content-Type: text/plain; charset=us-ascii; delsp=yes; format=flowed Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: [PATCH] libstdc++: Fix error shown during Solaris build From: Iain Sandoe In-Reply-To: <20201113111644.GH503596@redhat.com> Date: Fri, 13 Nov 2020 11:22:32 +0000 Cc: libstdc++@gcc.gnu.org, gcc-patches@gcc.gnu.org, Rainer Orth Content-Transfer-Encoding: 7bit Message-Id: References: <20201113110735.GA505111@redhat.com> <20201113111644.GH503596@redhat.com> To: Jonathan Wakely X-Mailer: Apple Mail (2.3273) X-Spam-Status: No, score=-3.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, 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: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2020 11:22:37 -0000 Jonathan Wakely wrote: > On 13/11/20 11:07 +0000, Jonathan Wakely wrote: >> Currently this is shown when building libstdc++ on Solaris: >> >> -lrt: open: No such file or directory >> >> The error comes from the make_sunver.pl script which tries to open each >> of its arguments. The arguments are passed by this make rule: >> >> perl ${glibcxx_srcdir}/scripts/make_exports.pl \ >> libstdc++-symbols.ver \ >> $(libstdc___la_OBJECTS:%.lo=.libs/%.o) \ >> `echo $(libstdc___la_LIBADD) | \ >> sed 's,/\([^/.]*\)\.la,/.libs/\1.a,g'` \ >> > $@ || (rm -f $@ ; exit 1) >> >> The $(libstdc___la_LIBADD) variable includes $(GLIBCXX_LIBS) which >> contains -lrt on Solaris. >> >> This patch adds another sed script to filter -l arguments from the echo >> command. In order to reliably match ' -l[^ ]* ' the echo arguments are >> quoted and a space added before and after them. This might be overkill >> just to remove -lrt from the start of the string, but should be robust >> in case other -l arguments are added to $(GLIBCXX_LIBS), or in case the >> $(libstdc___la_LIBADD) libraries are reordered. >> >> libstdc++-v3/ChangeLog: >> >> * src/Makefile.am (libstdc++-symbols.ver-sun): Remove -lrt from >> arguments passed to make_sunver.pl script. >> * src/Makefile.in: Regenerate. >> >> Tested sparc-solaris2.11. Rainer, does this look OK? >> >> Iain, the libstdc++-symbols.explist target for Darwin is very similar, >> but I don't know if it's a problem there. Does GLIBCXX_LIBS contain >> anything in $target/libstdc++-v3/src/Makefile on Darwin? >> >> Should we make the same change just in case? > > On examining acinclude.m4 it looks like GLIBCXX_LIBS could in theory > be non-empty for any target, including Darwin: > > elif test x"$enable_libstdcxx_time" != x"no"; then > > if test x"$enable_libstdcxx_time" = x"rt"; then > AC_SEARCH_LIBS(clock_gettime, [rt posix4]) > AC_SEARCH_LIBS(nanosleep, [rt posix4]) > else > AC_SEARCH_LIBS(clock_gettime, [posix4]) > AC_SEARCH_LIBS(nanosleep, [posix4]) > fi > > case "$ac_cv_search_clock_gettime" in > -l*) GLIBCXX_LIBS=$ac_cv_search_clock_gettime > ;; > esac > case "$ac_cv_search_nanosleep" in > -l*) GLIBCXX_LIBS="$GLIBCXX_LIBS $ac_cv_search_nanosleep" > ;; > esac > > AC_SEARCH_LIBS(sched_yield, [rt posix4]) > > case "$ac_cv_search_sched_yield" in > -lposix4*) > GLIBCXX_LIBS="$GLIBCXX_LIBS $ac_cv_search_sched_yield" > ac_has_sched_yield=yes > ;; > -lrt*) > if test x"$enable_libstdcxx_time" = x"rt"; then > GLIBCXX_LIBS="$GLIBCXX_LIBS $ac_cv_search_sched_yield" > ac_has_sched_yield=yes > fi > ;; > *) > ac_has_sched_yield=yes > ;; > esac > > But in practice the snippet above is only used if you explicitly > configure with --enable-libstdcxx-time={yes,rt} and will only add > anything to GLIBCXX_LIBS if clock_gettime or nanosleep lives in one of > librt or libposix4. I think libposix4 is Solaris-specific, and I don't > think Darwin has librt. So in practice I don't think there's a > problem on Darwin today. Agreed, neither of those libs is currently in use on Darwin. There have, in some cases, been library entries that are simply a symlink to the one providing the equivalent functionality, to minimize cross-platform build hassles - but I see no entry for librt.dylib or posix4. thanks Iain