All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Hatle <mark.hatle@windriver.com>
To: <yocto@yoctoproject.org>
Subject: Re: Building on MacOS X
Date: Thu, 12 Jan 2017 16:59:03 -0600	[thread overview]
Message-ID: <a0f910e1-e4e3-a36c-54f8-029cd72bae83@windriver.com> (raw)
In-Reply-To: <448FE605-0D5E-4057-BF49-9EFFBC5CB8DD@sentientblue.com>

On 1/12/17 11:41 AM, Roger Smith wrote:
>  I have Parallels (running on El Capitan the one before Sierra)  and ubuntu 14
>  running my current build environment on a MacBook Pro, but boy is the build
> slow… I also worked at Apple for 19 years on drivers inside MacOS X/iOS, so I am
> more than motivated to have this working natively rather than inside any
> container or disk space hogging environment.  As I mentioned I am working with
> the Intel Aero compute board, so slogging though all this fat to build an image
> is a productivity killer.

So take from this.. there is desire for oe/bitbake to work natively.  Most
people don't have the skill or free time to do the work.  A number of us started
it at one time or another and made enough progress to say "ya I think it's
possible" and then ran out of time.

As far as I know pseudo and the security introduced in 10.11 that affect
preloading is likely the biggest technical problem...  everything else is just
"it's not Linux".

--Mark

> I think most of the  incompatibilities between Linux and os x (which btw is
> coming from the ios side of the fence unfortunately), can be mitigated with boot
> args or via the command line . Apple’s compiler team had to make llvm compatible
> with gcc, so I am surprised if in 2017, there are compiler issues to building
> for an x86_64 platform with llvm on the Mac . That’s the kind of bug Apple likes
> to fix promptly.. 
> 
> As I mentioned, I tried to simply source the oe-init-build-env, and got an error
> that the readlink command that yocto is using is incompatible with the bsd
> version of readlink built into os x. 
> 
> i.e when I run .
> 
> source oe-init-build-env
> 
> I get the error
> 
> readlink: illegal option -- f
> 
> Which is because on OS X readlink doesn’t specify -f
> 
> YNOPSIS
>      stat [-FLnq] [-f format| -l | -r | -s | -x] [-t timefmt] [file...]
>      readlink [-n] [file...]
> 
> I didn’t want to go through this level of change in the Yocto sources if (1)
> people don’t care to take changes or (2) it had already been done before.. I was
> curious how far down this rabbit hole people had gone before..
> 
> Roger
> 
> 
>> On Jan 12, 2017, at 8:50 AM, Andrea Galbusera <gizero@gmail.com
>> <mailto:gizero@gmail.com>> wrote:
>>
>> On Thu, Jan 12, 2017 at 5:21 PM, Belisko Marek <marek.belisko@gmail.com
>> <mailto:marek.belisko@gmail.com>> wrote:
>>
>>     On Thu, Jan 12, 2017 at 4:39 PM, Tim Orling
>>     <timothy.t.orling@linux.intel.com
>>     <mailto:timothy.t.orling@linux.intel.com>> wrote:
>>     > You can also build using Docker containers:
>>     > https://github.com/crops/docker-win-mac-docs/wiki
>>     <https://github.com/crops/docker-win-mac-docs/wiki>
>>     Well the re is other limitation about slow filesystem access from
>>     docker on osx. There is workaround to use nfs but it's not possible to
>>     use nfs for building yocto - so it's kind of chicken-egg problem ;)
>>
>>
>> I shortly tested the CROPS docker-based setup after watching some presentation
>> at ELCE 2016 in Berlin. It basically worked but I experienced the filesystem
>> slowness your are talking about. I ended up waiting hours to see a simple
>> core-image-minimal build complete (even after giving more cores to docker).
>> One more point is that slightly more complex build scenarios, i.e. building
>> resin.os, also required tweaking docker run parameters for the build container
>> in order to give bitbake access to features like loop devices it needed (not
>> always easily debuggable issues indeed). Turned out I decided to stick with
>> more canonical linux based environments for the moment.
>>
>> Anyway, the technology behind CROPS is *very* interesting to me, and I'd like
>> to hear from people closely involved (Tim?) what the state of the art is and
>> what we can expect to see in the near future. IIRC, the roadmap for Yocto 2.3
>> release was supposed to resurrect the Eclipse plugin and adopt CROPS as an
>> alternative for running eSDK in a seamless way on different development host
>> OSs. Beside from the images on docker hub and the github projects that didn't
>> have high activity in the latest months, I hardly find discussions and
>> documentation on the whole approach. Isn't this hot enough anymore or are
>> there big issues that will prevent this technology from taking off. I often
>> manage SDKs for Windows-minded developers and I strongly yearn to find a
>> better approach to help them feel at home while building stuff for OE/Yocto
>> based systems... 
>>
>>  
>>
>>     >
>>     > On Jan 12, 2017, at 7:34 AM, Burton, Ross <ross.burton@intel.com
>>     <mailto:ross.burton@intel.com>> wrote:
>>     >
>>     >
>>     > On 12 January 2017 at 15:14, Roger Smith <roger@sentientblue.com
>>     <mailto:roger@sentientblue.com>> wrote:
>>     >>
>>     >> Is there any documentation for running the Yocto build system on Mac OS X
>>     >> or macOS as Apple now calls it? I am working with the Intel Aero board.
>>     >> Before I go down the rabbit hole of fixing issues like this one (and I am
>>     >> using the bash shell), I’d like to know if anyone has build it on os x
>>     >> before.
>>     >
>>     >
>>     > If you install all of the GNU tools using brew or similar and put them first
>>     > on $PATH then you can get bitbake started.  Then you need to stub out the
>>     > linux-specific bits in bitbake.  I've previously started on this work
>>     > already
>>     >
>>     (http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=ross/darwin
>>     <http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=ross/darwin>).
>>     > The next step is figuring out how to configure OE to build and link natively
>>     > on OSX using LLVM instead of GCC.
>>     >
>>     > However all of this is mostly academic because in Sierra (iirc) onwards
>>     > there is tighter security on processes, which means that pseudo won't work
>>     > even if you port it to macOS.
>>     >
>>     > So unless you fancy some non-trivial engineering the short version is just
>>     > use something like Docker to run a Linux system on your Mac.
>>     >
>>     > Ross
>>     > --
>>     > _______________________________________________
>>     > yocto mailing list
>>     > yocto@yoctoproject.org <mailto:yocto@yoctoproject.org>
>>     > https://lists.yoctoproject.org/listinfo/yocto
>>     <https://lists.yoctoproject.org/listinfo/yocto>
>>     >
>>     >
>>     >
>>     > --
>>     > _______________________________________________
>>     > yocto mailing list
>>     > yocto@yoctoproject.org <mailto:yocto@yoctoproject.org>
>>     > https://lists.yoctoproject.org/listinfo/yocto
>>     <https://lists.yoctoproject.org/listinfo/yocto>
>>     >
>>
>>     marek
>>
>>     --
>>     as simple and primitive as possible
>>     -------------------------------------------------
>>     Marek Belisko - OPEN-NANDRA
>>     Freelance Developer
>>
>>     Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
>>     Tel: +421 915 052 184 <tel:%2B421%20915%20052%20184>
>>     skype: marekwhite
>>     twitter: #opennandra
>>     web: http://open-nandra.com <http://open-nandra.com/>
>>     --
>>     _______________________________________________
>>     yocto mailing list
>>     yocto@yoctoproject.org <mailto:yocto@yoctoproject.org>
>>     https://lists.yoctoproject.org/listinfo/yocto
>>     <https://lists.yoctoproject.org/listinfo/yocto>
>>
>>
>> -- 
>> _______________________________________________
>> yocto mailing list
>> yocto@yoctoproject.org <mailto:yocto@yoctoproject.org>
>> https://lists.yoctoproject.org/listinfo/yocto
> 
> 
> 



  parent reply	other threads:[~2017-01-12 22:59 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-12 15:14 Building on MacOS X Roger Smith
2017-01-12 15:34 ` Burton, Ross
2017-01-12 15:39   ` Tim Orling
2017-01-12 15:42     ` Burton, Ross
2017-01-12 16:21     ` Belisko Marek
2017-01-12 16:27       ` Khem Raj
2017-01-12 16:50       ` Andrea Galbusera
2017-01-12 17:41         ` Roger Smith
2017-01-12 17:47           ` Burton, Ross
2017-01-12 22:59           ` Mark Hatle [this message]
2017-01-13  8:50             ` Clemens Lang
2017-01-14 19:45               ` Roger Smith
2017-01-14 19:49                 ` Tim Orling
2017-01-16 11:19                 ` Burton, Ross
2017-01-17  2:33                   ` Brian Avery
2017-01-12 22:32         ` Tim Orling
2017-01-12 17:55     ` Maciej Borzęcki
2017-01-12 18:03       ` Burton, Ross
2017-01-12 18:12       ` Andrea Galbusera
2017-01-12 18:43         ` Maciej Borzęcki
2017-01-12 22:16           ` Tim Orling
2017-01-12 15:38 ` Mark Hatle

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a0f910e1-e4e3-a36c-54f8-029cd72bae83@windriver.com \
    --to=mark.hatle@windriver.com \
    --cc=yocto@yoctoproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.