From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14245 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Reinoud Koornstra Newsgroups: gmane.linux.lib.musl.general Subject: Re: where to find musl-gcc wrapper script Date: Tue, 18 Jun 2019 14:49:17 -0700 Message-ID: References: <20190617233023.GK1506@brightrain.aerifal.cx> <20190618024755.GM1506@brightrain.aerifal.cx> <20190618174926.GN1506@brightrain.aerifal.cx> <20190618184346.GO1506@brightrain.aerifal.cx> <20190618213730.GQ1506@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="177538"; mail-complaints-to="usenet@blaine.gmane.org" Cc: musl@lists.openwall.com To: Rich Felker Original-X-From: musl-return-14261-gllmg-musl=m.gmane.org@lists.openwall.com Tue Jun 18 23:49:44 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1hdLz5-000k6b-Uj for gllmg-musl@m.gmane.org; Tue, 18 Jun 2019 23:49:44 +0200 Original-Received: (qmail 20368 invoked by uid 550); 18 Jun 2019 21:49:41 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 20348 invoked from network); 18 Jun 2019 21:49:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+W30Ftzoygc2EoCVRkomYyJug+gl5a19XHjgrvHC4ng=; b=qyuuEZjVYiz+gdZSDAvv9csd7/1y9V7iDDp0x0zNbQ536WxttcHZESCOa3UrneRbsd 7toNTWcX4GZ3Fpvs4KfTR8PaniwoQAKvP5oUZu5kvVHJjVhNeTVMVckjDC5lc3vLebvs JnQqJ/X69wP+fYxaVzwafsYnb4nuXfLfpoPrTITZjF3O7IjWoqFYGm+6nb17RV2YaGXB qulxtO/IhIbkPXdZLxSzFlBjsGmouhW1xYDTd+pGxhkGiWdu/8wsPGSiO4Qe+VTPwH6v YEP7o+NQWNP6HideFQCE5adFPBduF4eMgbiV2rjk2U/nGZtzQ69cN8vLKIm8LB0pltmT huyQ== 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:cc; bh=+W30Ftzoygc2EoCVRkomYyJug+gl5a19XHjgrvHC4ng=; b=nSWXdHRdV1HuSPIZQ7GCfF55UP5ZBCNBKZL+HdjfdEXLzSTgfpqA2Ku0TgiLxEbWYp HPfM1Pk7sEahMfF8mdGQzWaPJbheMei3JJG93gE2hhu92RDoL+AUhOXHDVIbYyvKd6br kWB23uY3bOQRTI2IYAzel80NzNDkItoKVFNno+bPvhXEQT3h7EHZj1fa8a7nQ2CsLoT2 csmb8fESzhISVN9xpbtAdcYbt3nuXgemiJ7DJ+mU9XnJ873tN5tNyQbt7aywNmJUgUnK 8WlpuP/DIVD06Oq1nYr4aIfMp50FLOP4GM40Rh2wtKo7IcZaMxs62gPnYilDuv3NlZaY 0wtw== X-Gm-Message-State: APjAAAU/8PZ6Qp1K0kwNumfOIeNSzqpjU2gfhlSCzU34hxte9UW9yvYq Hp/loxNj2W/fyJ/xMHH7UPk5GcQl+fORsJ5VY54= X-Google-Smtp-Source: APXvYqzyQqxS2aZVt5r6F6IWDtVC3UR5uWlVfuhy5pZ+ELUlDHQjJ5gbpQWwF0BwtvPKGyycnhtmPP+x48sxYg0vQHE= X-Received: by 2002:a9d:7601:: with SMTP id k1mr28606000otl.254.1560894568899; Tue, 18 Jun 2019 14:49:28 -0700 (PDT) In-Reply-To: <20190618213730.GQ1506@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:14245 Archived-At: On Tue, Jun 18, 2019 at 2:37 PM Rich Felker wrote: > > On Tue, Jun 18, 2019 at 02:19:06PM -0700, Reinoud Koornstra wrote: > > I noticed that the -static gives me some weird stuff. If I use glibc > > to compile gdb and then rerun the compile command with static I do get > > to see it's a statically linked binary. It'll end up with warnings, > > but ... > > gdb compiles fine with musl as well. So after compiling i see: > > ELF 32-bit executable, ARM, EABI5 version 1 (SYSV). dynamically > > linked, interpreter /lib/ld-musl-armhf.so.1 > > When I add -static to the arm-linux-musleabihf-g++ command it compiles > > seemingly fine as well. > > However when i run file again over this I see: > > ELF 32-bit executable, ARM, EABI5 version 1 (SYSV). dynamically > > linked, interpreter, /usr/lib/ld.so.1 .... > > So adding -static didn't seem to have the desired effect, it also all > > over sudden showed a different interpreter. > > Any ideas? > > What commands did you use to build musl-cross-make? Any config.mak > file? What options did you use when linking? in the config.mak for musl-cross-make I used: TARGET = arm-linux-musleabihf OUTPUT = /home/libnl/MUSL-ARM32 The rest I left default. To configure gdb-8.3 i used: Then I added OUTPUT to my path: PATH=/home/libnl/MUSL-ARM32/bin:$PATH I configured gdb with: CC=arm-linux-musleabihf-gcc CXX=arm-linux-musleabihf-g++ CFLAGS="-I/home/libnl/MUSL-ARM32/include" LDFLAGS="-L/home/libnl/MUSL-ARM32/lib" ./configure --enable-static --host=arm-linux-musleabihf --target=arm-linux-musleabihf --build=x86_64-ubuntu-linux after this I used make. Thanks, Reinoud. > > Rich > > > > On Tue, Jun 18, 2019 at 11:43 AM Rich Felker wrote: > > > > > > On Tue, Jun 18, 2019 at 11:27:51AM -0700, Reinoud Koornstra wrote: > > > > On Tue, Jun 18, 2019 at 10:49 AM Rich Felker wrote: > > > > > > > > > > On Mon, Jun 17, 2019 at 08:28:12PM -0700, Reinoud Koornstra wrote: > > > > > > On Mon, Jun 17, 2019, 7:47 PM Rich Felker wrote: > > > > > > > > > > > > > On Mon, Jun 17, 2019 at 07:30:00PM -0700, Reinoud Koornstra wrote: > > > > > > > > Ok the wrapper is included in the musl library itself in the obj > > > > > > > directory. > > > > > > > > > > > > > > Yes, or installed in $prefix/bin if you install. If you don't install > > > > > > > it won't be able to find its spec file. > > > > > > > > > > > > > > > c++ isn't supported yet? > > > > > > > > > > > > > > Right. Nobody I'm aware of understands the details of this, but > > > > > > > apparently either GCC's actual C++ headers or its "precompiled header" > > > > > > > versions of them pull in a bunch of stuff from glibc, and then it > > > > > > > breaks when you try to reuse them with musl. It's probably not that > > > > > > > hard to figure out the root cause and maybe even make it work, but > > > > > > > nobody has done it and interest is low because it's still a big hack > > > > > > > compared to just building a proper cross toolchain. > > > > > > > > > > > > > > > Currently I configure with CC=musl-gcc > > > > > > > > CFLAGS="-I/home/me/MUSL/include" LDFLAGS="-L/home/me/lib" ./configure > > > > > > > > the final g++ comand also add -lrt, need more changes for this to work? > > > > > > > > > > > > > > If you do that you're compiling against musl's headers but then > > > > > > > linking against glibc, which is going to make a huge broken mess. > > > > > > > > > > > > Yes, I noticed, so how can I force it to link against musl as well? > > > > > > > > > > You can't, because things already went wrong as soon as you compiled > > > > > against glibc's C++ headers using the glibc-based host g++. > > > > > > > > > > > > If you need C++, you really should just build a cross toolchain with > > > > > > > musl-cross-make. It's as simple as clining the mcm repo and running > > > > > > > "make TARGET=x86_64-linux-musl OUTPUT=/some/dir install" -- it will > > > > > > > download, check hashes on, and patch all the components you need and > > > > > > > give you a clean self-contained cross toolchain in the OUTPUT dir. > > > > > > > > > > > > > > > > > > > Also done that, in that case should I just use the compiled gcc as cc? > > > > > > > > > > You can pass the resulting x86_64-linux-musl-gcc and > > > > > x86_64-linux-musl-g++ as CC and CXX, but for software using the > > > > > standard tuple prefix conventions, you'd tell it you're cross > > > > > compiling for x86_64-linux-musl (e.g. by passing > > > > > --host=x86_64-linux-musl to configure) and it would automatically pick > > > > > them up as long as they're in your PATH (which you probably need to > > > > > add them to, e.g. PATH=$PATH:/path/to/mcm/output/bin). This is better > > > > > if the software has reason to need to know it's being cross compiled, > > > > > or if it uses other utilities like ar, ranlib, direct use of ld, etc. > > > > > in the build process, since it will pick up the right ones from the > > > > > cross toolchain. > > > > > > > > Ok, this seemed to have worked nicely. Question, it does add -lrt in > > > > the end, do I need this in musl or is it build in libc? > > > > Also, is there a way to verify everything linked nicely by the musl-ld? > > > > > > You can include -lrt or omit it; it doesn't matter. musl provides > > > librt purely as an empty static library file to allow link commands > > > that include it (POSIX specifies that it must be accepted), so it > > > makes no difference to the output. All functionality is in libc.a/.so. > > > > > > Rich