From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS22989 209.51.188.0/24 X-Spam-Status: No, score=-4.1 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id B8EFA1F461 for ; Tue, 14 May 2019 15:21:36 +0000 (UTC) Received: from localhost ([127.0.0.1]:49793 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hQZFH-0001FC-02 for normalperson@yhbt.net; Tue, 14 May 2019 11:21:35 -0400 Received: from eggs.gnu.org ([209.51.188.92]:52843) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hQZF7-0001DS-0W for bug-gnulib@gnu.org; Tue, 14 May 2019 11:21:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hQZF3-0003vl-MD for bug-gnulib@gnu.org; Tue, 14 May 2019 11:21:23 -0400 Received: from mail-io1-xd32.google.com ([2607:f8b0:4864:20::d32]:38020) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hQZEz-0003hr-Q8 for bug-gnulib@gnu.org; Tue, 14 May 2019 11:21:19 -0400 Received: by mail-io1-xd32.google.com with SMTP id x24so5904147ion.5 for ; Tue, 14 May 2019 08:21:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=MrP9HN9rOTzvYf3uUQpci/QsjDpBg+rFSobH1ZDViZA=; b=FjE0/bSiMZQAYVepFTCTIMwXGuTLEOPno8FWLbCBU80EN38B6jrDuzIJ9VHsUvixib oWZIu43NsJ5WYmKIMSpbU+7Q2wese4iHKDubaD6LvRJsFdltV8sT0mXhhi5qatuNuqUC 9ePZXK5WKwiHKakYYDQw1lBP/019R+c1zo+xgFpNhDZJds+WDw2GH1QHTiKnp7U6GOUC LL3aZ8NUHGg5ld3TEtd8wqyhjO8y6jPDoBYwfo7+FsVuJaZ6oJZjGshEOJdEwmYdUrtF +B8m82AxtGVqL2yzx6Dvjqivt5fCu78tuFGMSNu2ngTdc4686jsPyod3lidEq/Nmfe7Z mw/w== 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:reply-to :from:date:message-id:subject:to:cc; bh=MrP9HN9rOTzvYf3uUQpci/QsjDpBg+rFSobH1ZDViZA=; b=KQgp9Onuam6ubb8FwxDdvK9p8nR6jWgL3GXrwsSIv/R54wkktkp1ISUGz8nYP240bL 605ojd8V1YOJrUMIGGPghatGOA0WJE3Mi6ZiTLJUzh0y39gDsSiXeetrbBKOM4Jb/EKi vfsMQ0EdaEDfB0iy3LwBFpUvwZWxNfpAJ4zZZQap4NO9dMghBkYG83763FueWx2FNsD2 mxmrjHR481P/bksVLeKGg5MctF+0T6139DhvJQ4xHIHFpfeN+Uw9zz6rqsupxEzC55yD Q1uvn0ZS5vZc0cujC76EQBaqUXrOXs/DR6Vc35SpVfQkRYcjGQoXzae7DwOyC/oWwJne NTdA== X-Gm-Message-State: APjAAAW+PdglvuQKQfcpCKuDzxLXfimWK1LEm2a2PMTrTPnXiWLna23P EZQpAkzdMVUiP7EwFHoroBg9r5nlb+u6sDv4Poo1s2nY X-Google-Smtp-Source: APXvYqzarQxSNlVKbxTFjuI9UfAVUuFqx2cooY64MvaBgIY8UOFIRTTE0XXpzRezpqph9DOzYr+URIdhymjiLoj575s= X-Received: by 2002:a5d:898a:: with SMTP id m10mr12632522iol.296.1557847275522; Tue, 14 May 2019 08:21:15 -0700 (PDT) MIME-Version: 1.0 References: <2181955.gqDuHrTDux@omega> In-Reply-To: <2181955.gqDuHrTDux@omega> From: Jeffrey Walton Date: Tue, 14 May 2019 11:21:02 -0400 Message-ID: Subject: Re: Gnulib use of -Wl,-rpath To: Bruno Haible Content-Type: text/plain; charset="UTF-8" X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::d32 X-BeenThere: bug-gnulib@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Gnulib discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: noloader@gmail.com Cc: bug-gnulib@gnu.org Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: "bug-gnulib" On Tue, May 14, 2019 at 5:22 AM Bruno Haible wrote: > > Hi, > > Jeffrey Walton wrote: > > Second, here is a failed Gnulib runner. IDN's runner 3 does this: > > > > libtool: link: gcc -g2 -O2 -fsanitize=address -fno-omit-frame-pointer > > -march=native -fPIC -pthread -fsanitize=address -Wl,-R > > -Wl,/var/sanitize/lib64 -Wl,--enable-new-dtags -o tst_tld tst_tld.o > > -Wl,--no-as-needed -L/var/sanitize/lib64 libutils.a > > ../lib/.libs/libidn.so ../gl/.libs/libgnu.a -ldl -lpthread -pthread > > -Wl,-rpath -Wl,/home/build/libidn-1.35/lib/.libs -Wl,-rpath > > -Wl,/var/sanitize/lib64 > > gmake[2]: Leaving directory '/home/build/libidn-1.35/tests' > > gmake check-TESTS > > gmake[2]: Entering directory '/home/build/libidn-1.35/tests' > > gmake[3]: Entering directory '/home/build/libidn-1.35/tests' > > FAIL: tst_stringprep > > FAIL: tst_punycode > > ... > > In these cases, the following tools are useful (on ELF systems): > - ldd BINARY > which tells you how the runtime linker resolves the shared libraries > in the current situation, > - objdump -p BINARY | grep '\(NEEDED\|RPATH\|RUNPATH\)' > which tells you what information is encoded in the binary for the > runtime linker, > - readelf -d BINARY | grep '\(NEEDED\|RPATH\|RUNPATH\)' > likewise. > > > As I understand things an RPATH cannoth be overridden by > > LD_LIBRARY_PATH, while a RUNPATH can be overridden by a > > LD_LIBRARY_PATH. > > At least that's what [1] says. See also [2]. > > > In the failed run, notice two things. > > > > (1) my LDFLAGS (Wl,-R -Wl,/var/sanitize/lib64 -Wl,--enable-new-dtags) > > got overridden by Gnulib's LDFLAGS (-Wl,-rpath > > -Wl,/var/sanitize/lib64). > > They get combined, not overridden. Multiple -R or -rpath options are > cumulative. > > Did you also try -Wl,--disable-new-dtags instead of -Wl,--enable-new-dtags? > What is the outcome? Do the tests pass or fail? > > > (2) Gnulib's path does not include /home/build/libidn-1.35/gl/.libs, > > which is where Gnulib is located > > Yes, the LD_LIBRARY_PATH gets set in wrapper scripts that libtool > installs in the build tree, outside the .lib directories. > > > My question are, > > > > (1) why id Gnulib using a rpath instead of a runpath? > > The question (raised by [2]) is more: Why are some distros using a runpath > instead of an rpath, breaking 20 years of existing practice (see [3][5] > and [4])? > > > (2) why is Gnulib omitting /gl/.libs frm the runpath? > > Answered above. > > > (3) why are runpaths being set for a static archive? > > This option has no effect on static archives, I guess. Please verify this > using 'objdump' (see above). Thanks Bruno. I worked on this some more this morning. I ran '$ LD_DEBUG=libs tests/tst_stringprep' and it produced: ... 15300: calling preinit: tests/tst_stringprep 15300: 15300: /lib64/libasan.so.5: error: symbol lookup error: undefined symbol: __isoc99_printf (fatal) 15300: /lib64/libasan.so.5: error: symbol lookup error: undefined symbol: __isoc99_sprintf (fatal) 15300: /lib64/libasan.so.5: error: symbol lookup error: undefined symbol: __isoc99_snprintf (fatal) 15300: /lib64/libasan.so.5: error: symbol lookup error: undefined symbol: __isoc99_fprintf (fatal) 15300: /lib64/libasan.so.5: error: symbol lookup error: undefined symbol: __isoc99_vprintf (fatal) 15300: /lib64/libasan.so.5: error: symbol lookup error: undefined symbol: __isoc99_vsprintf (fatal) 15300: /lib64/libasan.so.5: error: symbol lookup error: undefined symbol: __isoc99_vsnprintf (fatal) 15300: /lib64/libasan.so.5: error: symbol lookup error: undefined symbol: __isoc99_vfprintf (fatal) 15300: /lib64/libasan.so.5: error: symbol lookup error: undefined symbol: xdr_quad_t (fatal) 15300: /lib64/libasan.so.5: error: symbol lookup error: undefined symbol: xdr_u_quad_t (fatal) 15300: /lib64/libasan.so.5: error: symbol lookup error: undefined symbol: swift_demangle (fatal) So I'm thinking I'm getting a bs error message, and I followed it down a rabbit hole. I still don't quite understand the why the presence of IDN in /usr/local affects it, though. They are nearly the same machines. Both are x86_64, both are Fedora, both have C/C++ developer tools, etc. I use build scripts so I have reproducible process on all machines I test on. The failing machine is Skylake, and the passing machine is Goldmont. The one difference I see is, failing machine in Fedroa 29, and passing machine is Fedora 28. It is counter intuitive to me - it seems like the F28 machine should be missing patches and broken. Here is a similar report. I don't know if it has something to do with it: https://github.com/google/sanitizers/issues/957. I've got 64-bit elf files, so I am not clear on the relation to a 32-bit bug report. Jeff