From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 20 23:51:59 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D43211065672 for ; Fri, 20 Jun 2008 23:51:59 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.173]) by mx1.freebsd.org (Postfix) with ESMTP id 4928E8FC13 for ; Fri, 20 Jun 2008 23:51:58 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: by ug-out-1314.google.com with SMTP id q2so85005uge.37 for ; Fri, 20 Jun 2008 16:51:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=42fSIWfwHhkulXx8NYOeg9pDfHVAIKPr8sQzbXO99Pc=; b=f564UwifRNKCp+QATx7oeFGEQ5UYYRxf2pl88spps+9RyHq/KKEONNzudBwCmkO0Au KJkf6Z3tXVS3Xq3in1hw24M72lk0FuBvqQ7rjU/HTPS1kzQPeOqc6H9x5F5qWc1ecDko B1IU3ouscUdHI3Z9rgWVRLHHkvh4ftGjvK25Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=ILvmiQd1ckj550u3p3XBiUCydH8uZcCHG9WLl7mEm8w67+BqUoQl4udj6iwlu+4h1B pbad4IC9Jac/AxpgM8fVdSLehz0ygKjuMY8A0d98AgZeqit/vCQy5VXx7qQEsNkc/Be3 Ks0AuSiFaNkrlLGKaIGta9YQNAWlabDw5GL1k= Received: by 10.210.25.20 with SMTP id 20mr3635249eby.46.1214005918086; Fri, 20 Jun 2008 16:51:58 -0700 (PDT) Received: by 10.210.22.4 with HTTP; Fri, 20 Jun 2008 16:51:58 -0700 (PDT) Message-ID: <3c0b01820806201651n70d0c903kae17298eefe152ec@mail.gmail.com> Date: Fri, 20 Jun 2008 19:51:58 -0400 From: "Alexander Sack" To: "Julian Elischer" In-Reply-To: <485C28E5.3070909@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3c0b01820806190629o7264cfaeg6fa6a08a6822047e@mail.gmail.com> <7d6fde3d0806190822s1420dcake3a38be7189b8ab0@mail.gmail.com> <3c0b01820806201352n54b846cas612a6923531ef04@mail.gmail.com> <485C1DC5.8090007@elischer.org> <3c0b01820806201424n53371437m8e9af5507416926e@mail.gmail.com> <485C28E5.3070909@elischer.org> Cc: Garrett Cooper , freebsd-hackers@freebsd.org Subject: Re: Cross platform building best practices (building 6 on 7) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2008 23:51:59 -0000 On Fri, Jun 20, 2008 at 6:02 PM, Julian Elischer wrote: > Alexander Sack wrote: >> >> On Fri, Jun 20, 2008 at 5:14 PM, Julian Elischer >> wrote: >>> >>> Alexander Sack wrote: >>>> >>>> On Thu, Jun 19, 2008 at 11:22 AM, Garrett Cooper >>>> wrote: >>>>> >>>>> On Thu, Jun 19, 2008 at 6:29 AM, Alexander Sack >>>>> wrote: >>>>>> >>>>>> Hello Folks: >>>>>> >>>>>> I've done a lot of Googling and scouring the lists about this >>>>>> particular subject so I apologize for rehashing it. However, I'm >>>>>> still confused on what's the best way to perform BSD cross platform >>>>>> builds. Ideally what I want to have is an environment whereby I can >>>>>> build a 6.1-RELEASE tree on a 7.0-RELEASE box. I thought originally I >>>>>> could check out a 6.1 release version, perform make world, and then >>>>>> use the output of that build as either a basis for a jail or a >>>>>> toolchain. However, as noted by previous threads, 6.x doesn't build >>>>>> on a 7.x due to gcc4/binutils compatibility issues (please correct me >>>>>> if I'm wrong). I then thought I could potentially download a patched >>>>>> binutils, copy it into src/contrib/binutils and that would potentially >>>>>> fix it. No dice (and I'm still debugging why since this binutils >>>>>> package DOES build outside of the make world infrastructure without >>>>>> issue, this very well could be pilot error on my part since I didn't >>>>>> update the VERSION string and didn't trim the source files as per the >>>>>> FreeBSD-deleteList etc.). >>>>>> >>>>>> I THEN thought if I build/install a gcc-3.x/bintuils toolchain I could >>>>>> complie a 6.x on a 7.x machine. Well I haven't done that yet since at >>>>>> this point I believe I'm diverged from the path of FreeBSD build >>>>>> enlightenment! Moreover, if would be NICE if I could bootstrap the >>>>>> normal dev tools from the exiting make world build tree. I'm not yet >>>>>> ready for a lot of hackery on the build tree without asking around. >>>>>> :D! >>>>>> >>>>>> Does anyone due cross-platform builds (without host virtualization)? >>>>>> >>>>>> Thanks! >>>>>> >>>>>> -aps >>>>> >>>>> (I'll stick to just hackers@ because I don't want to pollute >>>>> questions@ unnecessarily) >>>> >>>> Sorry I felt really bad actually cc'ing questions its just that my >>>> last groking produced many threads in freebsd-questions as opposed to >>>> hackers. I'll try to be more attentive to my posts (I have a habit >>>> cc'ing multiple forums because sometimes they apply but questions is >>>> for normal troubleshooting, not cross-platform build issues!). >>>> >>>>> You touched on an important point. There were some code quality issues >>>>> (I think) with 6.x that were resolved moving to 7.x, which caused >>>>> gcc-4.2.x to barf. >>>> >>>> Probably but I'm not trying to point fingers! :D! >>>> >>>>> gcc-4.2.x requires a newer version of binutils, just because (for API >>>>> / usage compatibility). >>>> >>>> Yea understood. To be honest, this isn't documented very readily. I >>>> first thought it was pilot error on me, then I decided to take a look >>>> at what failed to compile (I believe it was an innocent extern). And >>>> then got lost in gcc/binutils hell. Luckily I've smelled this problem >>>> before and after some research confirmed by suspicion. >>>> >>>>> What you should probably do is create a jail then do your development >>>>> for 6.x in a jail, 7.x in another, and (if you're bold enough ;)...) >>>>> do 8.x development in yet a third. Jail's are a much better way to >>>>> isolate things such that you don't have to worry about toolchain >>>>> issues like these and are able to setup a sourcebase as the devs >>>>> intended it (for the most part; you may run into issues with sysctls >>>>> and virtual kernel stuff like that, but cest la vie... there isn't a >>>>> better way I know of than that outside of running a VM). >>>> >>>> I figured you were going ot say that Garrett. Well OK, but I still >>>> need to bootstrap my dev environment for 6.x development on 7.x. >>>> Since binutils compatibility makes my 6.x make world barf on 7.x, >>>> where should I go? I HAVE not parsed through a lot of the build >>>> infrastructure yet but it would seem to be IF make world bootstraps >>>> the world including the development tools, why can't I update >>>> binutils/gcc inplace and then compile (or is this a regression issue >>>> which I failed to grasp). Or do I need to update binutils on my >>>> *host* system itself? i.e. what I'm really asking is does make world >>>> bootstrap the right bintuils/gcc etc. and then use THAT to compile the >>>> rest or does it just perform a host build of everything and plops it >>>> in DESTDIR? >>>> >>>> Hope I make some sense here (still a n00b).... >>> >>> One thing we always strive for in FreeBSD is an upgrade path. >>> >>> As a general rule, a newer system should be able to run a jail >>> populated with an earlier system. There are some small exceptions, >>> for example you may need a new version of netstat, ps and libkvm >>> in your jail. possibly grab them from the /rescue on the new system >>> so they are statically linked. >>> also 8.x systems will require that threaded programs from 6.x be >>> dynamically >>> linked so that they can be remapped to use libthr instead of libkse as >>> libkse is not supported in 8. >> >> So you are talking about binary/ABI compatibility yes? So I would >> assume what you are saying is I can take a 6.x system, create a >> filesystem tarball, drop it on a 7.x system and then create a jail out >> of it. >> >>> asside from those I think that just about every thing else should be >>> fine.. >>> I've run a FreeBSD 1.1 chroot on a freeBSD 7 system >>> (I had to make 1 very small fix). >>> >>> At Ironport we build 4.x binaries on 6.x systems by spinning off >>> a 4.x chroot as prart of the build process. (they need to link with 4.x >>> third party binaries) so it's very esay to do. >> >> I believe this answers my question but I want to confirm. I THOUGHT >> about this but I wanted a more *cleanroom* approach. That's all. > > this is about as cleanroom as you can get.. > you create a tarball of a virgin 6.x distribution including > virgin stuff you need, and then every time you need to do a > new 6.x jail, you just drop it in and hook it up. > > it doesn't even need to be a jail if you are just building.. > a chroot should be good enough. (with a /dev mounted in it usually) > (for /dev/null and such). Alright Julian, sounds reasonable. I just wanted to confirm on the list that this is really acceptable and I won't (generally speaking) run into any ABI issues (clearly on other platforms, this is NOT always the case!). Thanks again guys, -aps