From owner-freebsd-ppc@freebsd.org Thu Oct 11 00:20:02 2018 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BDAE710C0B26 for ; Thu, 11 Oct 2018 00:20:02 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-21.consmr.mail.gq1.yahoo.com (sonic306-21.consmr.mail.gq1.yahoo.com [98.137.68.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 482CE77EFC for ; Thu, 11 Oct 2018 00:20:02 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: ZegNRuYVM1m2bxJtHZKB5zq32IMpeKVD5oKQkGjPQCL2RQJSZpMJglwkWNLyVaO hierI6xO..PZ3sT8A.TowLlcKDhzcyUuxhwdlWXGCsideGjQnte8B8Cef9m77PgqATrw5hR4Ybt4 J4NeDm0t_edJG0mL.75TximM_llUjY.hCzt0YbjapSj_XD9SqCpfchjczUEpOUDK8zDKxsrzv3OQ HqIIVGiMQ0EHVjnTD9Md6_2.EICzpAtbm.54KguK5KB2ProZyvAsQAAoMAK7vgKRGOFZF8fjctjm ZhegYHPtLwXhtJC68N7vUGpXo01UIcHsfYhZPmZW5DB7PzW0msOYSMuoupQbOjOkb7YMdlLX03ng gxSiuaZzqv76GSdZ.ofjWqYPxSw.EcrOIYdit2FuWPJ6AG1_0Cb76OBl_xhFQGcTtlnvHOohrwZC 2ahRvC4lJ69hqr7iGnWXxf2jkCLfakmRHeE117fPaLLwVgqh2pTZZfARFg2T4nGwuwUv8PanI9OP RB8q2yOijD95fQ5TAlt6wBIZb06oNuO7kO36bODWp5prpWzrTKPFeT8Thu02.BfVRWRuch_J504Z S3eAqjM0YUn8tUDYlHe4xI95g3DuYS555exG4phroBTL1GaROUerv8UNGw2mlyQ2s_vr7Wa5xHJY Ew9uY6EHuPWWc53Wf5eLqf7qgmkSM3BrV2DVdVr0RuSHjEiTW3MX4DWsMH6Eq.xbHmFM4QvLRTby rdI9w0M5EflHlORci.QYt05RFtHnFNFYaDYC57jzKgOZAopbLbOUJSwXq7M0qPHEQfI2ZiSxBLuF HNSph8hd3UfngorePSwt09IHWQmqdGMX9p_mRvFsqLTpJgvbfABgTH6FMERsHB_gxKveJnbYjFVn fv1qomujrwcVxXCMudPu3QoAoovYGU08yAEMRhn6nQojt2gII7ZZS9lf14ZKpPGR9b9d7KzfyQiT ShAG5ycVsGLJh_TA35QxZJApvKg2q_KS0PNlN.U7Q1XVoXOi6F1YYcvdI14MpawKcKK4NNVPrtOL _zI.rsDE5muJoSbBPB7tRP.x.eLK2vbvVgbNntWxrsYbw99BuIjWSynsaV1K4hjXu7.5sMcVcpbq JWD.rKtQ- Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Thu, 11 Oct 2018 00:19:53 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp428.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID dec724c1e4b3d40b3abe02b231b9bed8; Wed, 10 Oct 2018 23:59:34 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: base/binutils vs. /usr/local/lib references and also: undefined reference to `pthread_create' (powerpc64 targeting example) From: Mark Millard In-Reply-To: <3c10995e-2c84-a140-ed4d-449ce61d3d05@FreeBSD.org> Date: Wed, 10 Oct 2018 16:59:33 -0700 Cc: FreeBSD Toolchain , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C338B84-1179-4569-A964-CA18A22AF1D7@yahoo.com> <3c10995e-2c84-a140-ed4d-449ce61d3d05@FreeBSD.org> To: John Baldwin X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2018 00:20:03 -0000 On 2018-Oct-10, at 3:13 PM, John Baldwin wrote: > On 10/6/18 12:22 PM, Mark Millard via freebsd-toolchain wrote: >> [Actually devel/gettext-tools is a build time dependency: it should = not be using >> libtool: link: /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc = --sysroot=3D. . . >> It looks like the /usr/local/lib references are correct but the wrong = linker was >> being used. About 5 other ports have a similar status for making = base/binutils >> as a cross build.] >=20 > base/binutils should not be pulling in any other ports at all. = Everytime I've > built it it has had no other dependencies beyond pkg. As far as I'm = aware,=20 > the only ports which work with CROSS_TOOLCHAIN and CROSS_SYSROOT are > ports-mgmt/pkg, base/gcc, and base/binutils. If devel/gettext-tool is already installed, things just work. In such a context the dependency is less likely to be noticed. >> On 2018-Oct-5, at 11:00 PM, Mark Millard = wrote: >>=20 >>> In trying to follow the base/binutils part of = https://wiki.freebsd.org/ExternalGCC >>> (or /usr/ports/base/README) for targeting powerpc64 I got: >>>=20 >>> ( My /etc/make.conf has: WRKDIRPREFIX?=3D/wrkdirs .) >>>=20 >>> # cd ../../base/binutils/ >>> # make CROSS_TOOLCHAIN=3Dpowerpc64-gcc = CROSS_SYSROOT=3D/usr/obj/DESTDIRs/xtcgcc-powerpc64-installworld package >>> . . . >>=20 >> Note: This should involve building devel/gettext-tools targetting = amd64 >> (the host environment in this example) because devel/gettext-tools is >> a build-time dependency, not to be run on the target system. >=20 > Maybe install gettext on your system first before doing the build. = Probably > the CROSS_* aren't stripped from the environment when building = dependencies. That is what I did and it worked fine after devel/gettext-tool had already been installed. In general build-time dependencies are more likely to be for the host environment's execution and run-time dependencies are more likely to be for the target's execution. (But if something is both, then likely both forms are needed, tracking HOST vs. TARGET for where used.) I do not see evidence of such considerations in the ports infrastructure. So I expect "install gettext on your system first before doing the build" should be a standard part of the instructions for base/binutils --at least for now. >> May be if devel/gettext-tools had been pre-built and installed >> before trying the CROSS_TOOLCHAIN=3Dpowerpc64-gcc >> CROSS_SYSROOT=3D/usr/obj/DESTDIRs/xtcgcc-powerpc64-installworld >> based build activity it would have been okay? >>=20 >> [I try such later below and report on the results.] >>=20 >> There are no words on https://wiki.freebsd.org/ExternalGCC or >> in /usr/ports/base/README for such special build-sequence >> instructions. >=20 > You're maybe the 3rd person trying it. :-/ Long ago I submitted bugzilla reports when I first tried it. A lot of that was addressed later. It was much nicer to explore the 2nd time. And, for what I used this time, even nicer now. >>> (It is also unclear how the process involving base/* mixes with = doing >>> later FreeBSD updates from source --including any use of a = delete-old >>> step if WITHOUT_BINUTILS=3D is used at the time. For the cross = buildworld >>> itself it is not clear what options are intended.) >=20 > So I plan on having a freebsd-gcc.mk (or freebsd-cc.mk) toolchain file > that base/gcc will install that will set WITHOUT_BINUTILS and some = other > things. I have manually done that for now when building world inside = a > MIPS qemu instance using base/binutils and base/gcc as the native = toolchain. > Once I have a build that actually finishes I plan to add the toolchain = to > the port and then have Makefile.inc1 automatically include the file it = is > present. I'm actually only using the pkg cross build and the base/binutils cross build. The existing src.conf/make.conf infrastructure already allowed me to build or cross-build based on devel/powerpc64-gcc (via devel/powerpc64-xtoolchain-gcc) and I've been doing that for years and clang is useful for powerpc ( but not good for buildworld buildkernel ). WITHOUT_BINUTILS=3D use has the consequences that delete-old will delete base/binutils materials (and so base/binutils materials have to be put back afterwards). That is what I've been doing. I actually have the build include clang and set up clang as cc for the target (no bootstrap clang). Clang's powerpc family problems are tied to special aspects associated with buildworld and buildkernel . Right now I've a poudriere-devel building what expanded to 414 ports on the old PowerMac G5, based on system-clang and the base/binutils material. One thing that I use is WITHOUT_LIB32=3D because any modern gcc that I've tried sticks in a R30 use in crtbeginS code that does not follow the powerpc family ABI FreeBSD is based on for this code: 32-bit powerpc code just produces core files on powerpc64 --from the bad dereference of R30 as holding an context-defined address. If I remember right, base/gcc had this problem for targeting powerpc64 as well. If there was a devel/powerpc-gcc and devel/powerpc-binutils and devel/powerpc-xtoolchain-gcc I could do the same for the 32-bit context. >>> Notes about some typos on: https://wiki.freebsd.org/ExternalGCC >>>=20 >>> /usr/ports/devel/ports-mgmt/pkg should be: >>> /usr/ports/ports-mgmt/pkg >>>=20 >>> 3 examples of CROSS_TOOCLAHIN should be: >>> CROSS_TOOLCHAIN >=20 > Fixed. Thanks. >>> Notes about the /usr/ports/base/README : >>>=20 >>> No mention is made of the pkg build so that it can be >>> set up on the target. Only https://wiki.freebsd.org/ExternalGCC >>> has that information. /usr/ports/base/README does not >>> reference https://wiki.freebsd.org/ExternalGCC either. >=20 > The README predates the wiki page by a fair bit. Ahh. I see. > The current known issue I need to get back to with base/gcc is that it > improperly looks for libraries in /usr/lib when --sysroot is used. I = need > to get that fixed so that a buildworld via base/gcc works correctly = and then > I will probably get back to working on more of the todo items on the = wiki > page. >=20 Other than when I explicitly go to test base/gcc, I do not see such because I use the src.conf/make.conf ways of putting devel/powerpc64-gcc and such to use and have the build include clang as cc: no use of base/gcc. I've not tested base/gcc in a long time. I do this style of buildworld buildkernel on the PowerMac G5's too: a = sort of "self hosted cross build". =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)