From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10972 invoked by alias); 17 Jan 2018 17:54:10 -0000 Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org Received: (qmail 10931 invoked by uid 89); 17 Jan 2018 17:54:10 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=opinion, GROUP, our, you! X-HELO: rock.gnat.com Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 17 Jan 2018 17:54:08 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 1B76C117E54; Wed, 17 Jan 2018 12:54:07 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id fs9kBQfAlmdb; Wed, 17 Jan 2018 12:54:07 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id E3549117E46; Wed, 17 Jan 2018 12:54:06 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 694F583304; Wed, 17 Jan 2018 18:54:05 +0100 (CET) Date: Wed, 17 Jan 2018 17:54:00 -0000 From: Joel Brobecker To: binutils@sourceware.org Cc: Douglas Rupp , Erwan Le Guillou Subject: question about sysroot and Windows->Linux cross ld Message-ID: <20180117175405.6elswkryoba5yq3d@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: NeoMutt/20170113 (1.7.2) X-SW-Source: 2018-01/txt/msg00267.txt.bz2 Hello, We are working on a a Windows-to-Linux compiler, and we noticed something with respect to shared library linking which looks like it might be a bug, and we'd like to have your opinion before we go too deep into trying to solve this. We created a sysroot on the host by copying the various headers and libraries from our target. We then passed that sysroot to the compiler using --sysroot=/path/to/sysroot. A cross-compiler hosted on GNU/Linux is able to link a program fine, but the same cross-compiler hosted on Windows fails to link with the following error: | c:/[...]/gcc/install/bin/../libexec/gcc/powerpc-generic-linux-gnu/6.4.1/ld.exe: cannot find //lib/libc.so.6 | c:/[...]/gcc/install/bin/../libexec/gcc/powerpc-generic-linux-gnu/6.4.1/ld.exe: cannot find //lib/libc_nonshared.a | c:/[...]/gcc/install/bin/../libexec/gcc/powerpc-generic-linux-gnu/6.4.1/ld.exe: cannot find //lib/ld.so.1 | collect2.exe: error: ld returned 1 exit status Investigating a bit, we found that some of the shared libraries are ld scripts. In particular, one of them contains: | /* GNU ld script | Use the shared library, but some functions are only in | the static library, so try that secondarily. */ | OUTPUT_FORMAT(elf32-powerpc) | GROUP ( //lib/libc.so.6 //lib/libc_nonshared.a AS_NEEDED ( //lib/ld.so.1 ) ) After reading the documentation a bit and tweaking around, we found that if we replaced the paths above to start with "=/" instead of "//" (eg: "//lib/" -> "=/lib"), the linker is able to find the shared library inside our sysroot. In other words, unless we prefix the paths in the ld script with '=', it seems like ld is not applying the sysroot as one might expect. Given that the same command with the same sysroot but hosted on a GNU/Linux machine works, we're thinking this might be a bug, either in the linker itself, or perhaps in the way we build the linker. Any opinion on this? We'll investigate the problem, but it would help us if we knew that we're trying to achieve the correct result :). Thank you! -- Joel