re read what he said. i think you misunderstood him.

On 11/17/2015 5:32 PM, John Syne wrote:
> Hi William,
>
> I don’t want to prompt an argument here, but I am curious. Where is it
> that you believe Windows adds value here? I accept that you have a
> windows machine, but why not run Debian or Ubuntu on Virtualbox or
> VMWare and avoid all the complications of Windows? I use OSX for all
> my Nodejs/Angularjs/HTML development and then I use Ubuntu for my
> embedded development. The only reason I use Windows is to run
> Solidworks and Altium, and my only hope is that one day I can run
> these on OSX or Linux. 
>
> Regards,
> John
>
>
>
>
>> On Nov 17, 2015, at 3:41 PM, William Hermans <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>>     /I ended up installing Debian Jessie on an old Macbook (the
>>     original one actually, version 1,1) and everything just works
>>     great with it. After playing around a bit on the Mac I decided to
>>     buy a new Dell XPS 13 for development (warning there... you'll
>>     need to run Debian unstable with the 4.3 experimental kernel in
>>     order to support the new Skylake architecture but figuring all
>>     that out was MUCH easier than trying to build a cross compiler
>>     toolchain for Xcode). As for getting get the USB working... I
>>     never did but it looks like there's been some progress in the
>>     past few weeks. Check out Robert's post. /
>>
>>
>> This is probably the best move anyone could make. That is using an
>> i386 / i386-64 Linux ( and why not debian ? ) system for development.
>> There are simply too many factors to consider when using anything
>> else, and while probably not impossible. It is simply too much of a
>> hassle.
>>
>> So, I run Windows, and have the capability to use Linaro's Windows
>> binaries for a cross toolchain - But I don't. I've actually set this
>> up with code:blocks, and it works fine. But there are so many dahmed
>> hoops to jump through for even the simplest things like using a third
>> party library. It's just not worth it.
>>
>> Passed that though . . .
>>
>>  1. Mount an NFS share on the Beglebone from this dev system.
>>  2. Set up a Samba share from that NFS share root.
>>  3. Map that Samba share on your host system.
>>  4. Use editor of choice, on host to write code that seems local, but
>>     is actually remote.
>>  5. Compile natively on the Beaglebone using ssh / gcc, etc.
>>
>>
>> Definitively there are simply ways to get a single file, or a few
>> files over to the target(Beaglebone ). But for multiple files /
>> projects this is the method that I personally find the best / easiest.
>>
>> On Tue, Nov 17, 2015 at 1:26 PM, Joe Ciarcia <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>>     I gave up on using OS X El Cap and Xcode for development on the
>>     Beaglebone. I posted to the crosstool-ng list to see if anyone
>>     could help with the errors I was seeing and I didn't get any
>>     responses (even though it's a pretty active list, I just suspect
>>     very few people are trying to do cross platform development for
>>     the arm on a Mac). I ended up installing Debian Jessie on an old
>>     Macbook (the original one actually, version 1,1) and everything
>>     just works great with it. After playing around a bit on the Mac I
>>     decided to buy a new Dell XPS 13 for development (warning
>>     there... you'll need to run Debian unstable with the 4.3
>>     experimental kernel in order to support the new Skylake
>>     architecture but figuring all that out was MUCH easier than
>>     trying to build a cross compiler toolchain for Xcode). As for
>>     getting get the USB working... I never did but it looks like
>>     there's been some progress in the past few weeks. Check out
>>     Robert's post. 
>>
>>     As for connecting to it via ethernet (which is pretty easy)...
>>     you can either connect it directly to the ethernet port on your
>>     Mac, or you can connect it to your router. To log in all you have
>>     to do is open a terminal and ssh in...
>>
>>     ssh [email protected] <mailto:[email protected]>
>>
>>     You don't have to fool around with IP addresses etc. as most of
>>     the tutorials indicate. Much easier that way. Once you're in
>>     though, create a new user so that you're not using root all the time.
>>
>>     If you want to go the Debian route, I highly recommend this video
>>     from Derek Molloy to get things started. It will show you how to
>>     get the Eclipse IDE up and running which will allow you to do
>>     cross compilation, remote deployment of your binaries, and remote
>>     debugging. It's pretty slick!
>>
>>     https://www.youtube.com/watch?v=T9yFyWsyyGk
>>
>>     Cheers, Joe
>>
>>     On Tuesday, November 17, 2015 at 2:11:30 PM UTC-5,
>>     [email protected] <mailto:[email protected]> wrote:
>>
>>         Dear Joe,
>>
>>         I see you are running os 10.11, me too.
>>         I'm not getting the BBB to be recognized by my mac.
>>         And when i'm trying to install the Serial driver, i get an error
>>         Can you help me?
>>
>>         Op zaterdag 24 oktober 2015 16:27:43 UTC+2 schreef Joe Ciarcia:
>>
>>             I've found some great resources out there that help us
>>             Mac folk out with building an arm toolchain on the OS X
>>             platform. Here they are if any others stumble across this
>>             thread looking for the same:
>>
>>             http://www.benmont.com/tech/crosscompiler.html
>>             http://will-tm.com/cross-compiling-mac-os-x-mavericks/
>>             
>> http://hansbot.blogspot.com/p/beaglebone-black-mac-os-x-toolchain.html
>>              (this one is the most detailed)
>>
>>
>>             I've gotten through a few of the stumbling blocks but I'm
>>             currently stuck. I get this far:
>>
>>             [INFO ]  Performing some trivial sanity checks
>>
>>             [INFO ]  Build started 20151023.200552
>>
>>             [INFO ]  Building environment variables
>>
>>             [00:03] /
>>
>>
>>             So, after that, if I look at the activity monitor, bash
>>             is around 100% processor utilization on one of the cores.
>>             I figure "great, it's doing something". I left it to do
>>             its thing and after an hour, I killed the process. I
>>             changed a few settings... ran it again... same thing.
>>             Okay... maybe it just takes a really long time. I left it
>>             overnight. This morning it was still near 100% processor
>>             utilization and nothing had changed in the build.log
>>             file. Here's the last few lines from the build log:
>>
>>
>>             [DEBUG] 
>>             =================================================================
>>
>>             [DEBUG]  Checking that we can run gcc -v
>>
>>             [DEBUG]    ==> Executing:
>>             'x86_64-build_apple-darwin15.0.0-gcc' '-v' 
>>
>>             [DEBUG]    Configured with:
>>             --prefix=/Applications/Xcode.app/Contents/Developer/usr
>>             --with-gxx-include-dir=/usr/include/c++/4.2.1
>>
>>             [DEBUG]    Apple LLVM version 7.0.0 (clang-700.1.76)
>>
>>             [DEBUG]    Target: x86_64-apple-darwin15.0.0
>>
>>             [DEBUG]    Thread model: posix
>>
>>             [DEBUG]  Checking that we can run gcc -v: done in 0.00s
>>             (at 00:03)
>>
>>             [DEBUG] 
>>             =================================================================
>>
>>             [DEBUG]  Checking that gcc can compile a trivial program
>>
>>             [DEBUG]    ==> Executing:
>>             'x86_64-build_apple-darwin15.0.0-gcc' '-O2' '-g' '-pipe'
>>             
>> '/Volumes/CaSe/.build/arm-JoesBeaglebone-linux-gnueabi/build/test.c'
>>             '-o'
>>             '/Volumes/CaSe/.build/arm-unknown-linux-gnueabi/build/.gccout' 
>>
>>             [DEBUG]  Checking that gcc can compile a trivial program:
>>             done in 0.00s (at 00:03)
>>
>>             [EXTRA]  Installing user-supplied crosstool-NG configuration
>>
>>             [DEBUG]  ==> Executing: 'mkdir' '-p'
>>             '/Volumes/CaSe/prefix/bin' 
>>
>>             [DEBUG]  ==> Executing: 'install' '-m' '0755'
>>             
>> '/usr/local/Cellar/crosstool-ng/1.21.0/lib/ct-ng.1.21.0/scripts/toolchain-config.in
>>             <http://toolchain-config.in/>'
>>             
>> '/Volumes/CaSe/prefix/bin/arm-unknown-linux-gnueabi-ct-ng.config' 
>>
>>             [ERROR]  
>>
>>             [ERROR]  >>
>>
>>             [ERROR]  >>  Build failed in step '(top-level)'
>>
>>             [ERROR]  >>
>>
>>             [ERROR]  >>  Error happened in:
>>             CT_DoExecLog[scripts/functions@216]
>>
>>             [ERROR]  >>        called from:
>>             main[scripts/crosstool-NG.sh@564]
>>
>>             [ERROR]  
>>
>>
>>             [ERROR]  (elapsed: 756:57.00)
>>
>>
>>             Any suggestions on how to debug this? Obviously it's
>>             attempting to do something given the processor
>>             utilization but... what the heck is it hung up on?
>>
>>
>>             One thing worth noting... early in the process the build
>>             log had an error with regards to not being able to find
>>             the ginstall tool. Since this was at the beginning of the
>>             test process I figured it hadn't gotten to building
>>             anything yet and as such, ct-ng clean was not needed
>>             (maybe I'm wrong). As part of running ct-ng build it
>>             creates a directory structure (running clean deletes this
>>             structure and all the tools included) at
>>             /YourCaseSensitiveDirectory/.build/tools/bin. My solution
>>             was to just cp install ginstall, and that got me past
>>             that error. Not sure if that's contributing to anything
>>             but I thought it worth mentioning. Is there another way
>>             around the missing ginstall problem?
>>
>>
>>             Cheers, Joe
>>
>>
>>
>>     -- 
>>     For more options, visit http://beagleboard.org/discuss
>>     ---
>>     You received this message because you are subscribed to the
>>     Google Groups "BeagleBoard" group.
>>     To unsubscribe from this group and stop receiving emails from it,
>>     send an email to [email protected]
>>     <mailto:[email protected]>.
>>     For more options, visit https://groups.google.com/d/optout.
>>
>>
>>
>> -- 
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to the Google
>> Groups "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it,
>> send an email to [email protected]
>> <mailto:[email protected]>.
>> For more options, visit https://groups.google.com/d/optout.
>
> -- 
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google
> Groups "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to [email protected]
> <mailto:[email protected]>.
> For more options, visit https://groups.google.com/d/optout.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to