Forum Update - Announcement about May 10th, 2018 update and your password.

Building PropGCC with Docker

2»

Comments

  • David Betz wrote: »
    dgately wrote: »
    DavidZemon wrote: »

    BTW: Once I got gccv6 to build, I was only able to exec propeller-elf-gcc within Docker (because of course, it is an x86 elf executable, which won't run under macOS native). So, I've got to figure out how to create a macOS variant, similar to how you created a WIN variant? Or, am I totally off here?

    dgately
    When you're running inside of David's Docker container you're essentially running under Ubuntu Linux, right? So it should be able to run Linux x86 executables.

    Yes, inside the Docker container, you are running Linux. On a native Linux host machine, it uses the host's kernel, which is what makes Docker (and other container solutions) extremely lightweight compared to VM solutions. On Windows and Mac, it actually starts a slimmed down Linux VM and then boots up Docker inside that VM. I would imagine it only starts a single VM per Windows host - not a VM for each container running on that host - but won't swear to that.
    dgately wrote: »
    DavidZemon wrote: »

    BTW: Once I got gccv6 to build, I was only able to exec propeller-elf-gcc within Docker (because of course, it is an x86 elf executable, which won't run under macOS native). So, I've got to figure out how to create a macOS variant, similar to how you created a WIN variant? Or, am I totally off here?

    dgately

    Docker won't bring us any closer to building PropGCC for Mac than we were before. As you now understand from my explanation above, we're Linux, just the same as if I was building locally on my own box. The only difference is that now we have a Docker "image" that will remain identical on both your machine and mine. We still don't know how to cross-compile Linux -> Mac. :(
    David
    PropWare: C++ HAL (Hardware Abstraction Layer) for PropGCC; Robust build system using CMake; Integrated Simple Library, libpropeller, and libPropelleruino (Arduino port); Instructions for Eclipse and JetBrain's CLion; Example projects; Doxygen documentation
    CI Server: http://david.zemon.name:8111/?guest=1
  • OK, I get it... It's still quite useful in that I can build propeller C projects with gccv6, now. I just can't run a native macOS IDE app (i.e. SimpleIDE) expecting to execute this propeller-gcc compiler from within.

    I'm also trying to build propeller-gcc (v6) natively on macOS and the logged results of these (gccv4 & gccv6) builds may help in debugging the native build.

    Thanks,
    dgately
    Livermore, CA (50 miles SE of San Francisco)
  • Exactly. However, if you're willing to run an X-server on Mac, you could use my other Docker image which has all of the tools pre-installed and simply point SimpleIDE (or any other graphical tool) to the X-session on your host. Docker also has a way to mount your serial device (if Mac is anything like Linux, and makes serial devices available as files such as /dev/ttyUSB0), which then lets you even write programs to the Propeller from within the Docker image.

    In my earlier thread, I had that working: https://forums.parallax.com/discussion/comment/1429926/#Comment_1429926
    David
    PropWare: C++ HAL (Hardware Abstraction Layer) for PropGCC; Robust build system using CMake; Integrated Simple Library, libpropeller, and libPropelleruino (Arduino port); Instructions for Eclipse and JetBrain's CLion; Example projects; Doxygen documentation
    CI Server: http://david.zemon.name:8111/?guest=1
  • Good news! The build server is finally building PropGCC artifacts again now that the TeamCity/Docker bug has been fixed. The latest binaries are all live again. The Linux binaries were tested to the extent that the Windows and Raspberry Pi builds had to use them during the build process... other than that, none of the 6 packages have been tested at all. Not that I expect any issues. But please, if you do download one and run into an issue, let me know and I'll get it fixed.
    David
    PropWare: C++ HAL (Hardware Abstraction Layer) for PropGCC; Robust build system using CMake; Integrated Simple Library, libpropeller, and libPropelleruino (Arduino port); Instructions for Eclipse and JetBrain's CLion; Example projects; Doxygen documentation
    CI Server: http://david.zemon.name:8111/?guest=1
  • DavidZemon wrote: »
    Good news! The build server is finally building PropGCC artifacts again now that the TeamCity/Docker bug has been fixed. The latest binaries are all live again. The Linux binaries were tested to the extent that the Windows and Raspberry Pi builds had to use them during the build process... other than that, none of the 6 packages have been tested at all. Not that I expect any issues. But please, if you do download one and run into an issue, let me know and I'll get it fixed.

    Thanks, David!

  • A key point to consider; If your host system, read favorite system for running Parallax tools, is definitely 64 bit and is Window 7 (any release) but behaves as if it is really 32 bit, when wanting to run the Docker management device, it won't work.

    I found that out earlier on, say back in November of 2009 when I wanted to run virtual machine supporting things like VMware and even Virtual Box, and then Virtual PC, it turn out that this fellow is really running an advanced Pentium design, and is just the beginning of the I anything series of systems, such as the fast back systems that the rest of us run. It's like this, I can run VMware and Virtual PC, but not VB. VMware won't support 64 bit guests. Oh and it turns out that the special guest OS virtualization things that's very popular in later system isn't here.

    But the really strange thing is that when the host is running Linux native, on a different disk drive, the OS works as if it doesn't matter. And the community version of Docker works. I've not gotten around to trying your Docker image for building this PropGCC vehicle, but that's next.
  • ... but behaves as if it is really 32 bit...

    I think those words are key to understanding your post... but I don't understand them. If I leave that snippet out, then your entire post makes no sense to me. Docker says, right at the top of step 1 for installing on Windows: "To run Docker, your machine must have a 64-bit operating system running Windows 7 or higher." which seems to match your system perfectly. So you shouldn't have any issues with that. And many of my co-workers are running 64-bit Windows 7 installations with Oracle VirtualBox and Linux guest machines. So... what do you mean by "behaves as if it is really 32 bit"
    David
    PropWare: C++ HAL (Hardware Abstraction Layer) for PropGCC; Robust build system using CMake; Integrated Simple Library, libpropeller, and libPropelleruino (Arduino port); Instructions for Eclipse and JetBrain's CLion; Example projects; Doxygen documentation
    CI Server: http://david.zemon.name:8111/?guest=1
  • DavidZemon wrote: »
    ... but behaves as if it is really 32 bit...

    I think those words are key to understanding your post... but I don't understand them. If I leave that snippet out, then your entire post makes no sense to me. Docker says, right at the top of step 1 for installing on Windows: "To run Docker, your machine must have a 64-bit operating system running Windows 7 or higher." which seems to match your system perfectly. So you shouldn't have any issues with that. And many of my co-workers are running 64-bit Windows 7 installations with Oracle VirtualBox and Linux guest machines. So... what do you mean by "behaves as if it is really 32 bit"

    Think about this, preferably with a good cup of coffee in hand, or in front of you. One of the key advances in the Intel I-series of processors, and in the matching ones from AMD, in their AMD64 series of designs, is a virtual-assist feature bit, that when enabled makes doing that possible. This machine whilst it is indeed 64-bit, is from the period when the Intel was busily moving from regular 64 bit processors after the failure of the design based on the Dec Alpha became fact, to their I-series of systems.

    It says "Pentium Inside" it does not say I-series inside.

    That's what the post you responded to means. If we waited another few weeks that year, to order, it would have been. It's not really problem.

    And yes the Docker pages do say that.
  • Interesting. I wish I could see that first hand. Of course... I don't happen to have any Pentium (4, presumably?) chips laying around to play with :P
    David
    PropWare: C++ HAL (Hardware Abstraction Layer) for PropGCC; Robust build system using CMake; Integrated Simple Library, libpropeller, and libPropelleruino (Arduino port); Instructions for Eclipse and JetBrain's CLion; Example projects; Doxygen documentation
    CI Server: http://david.zemon.name:8111/?guest=1
  • DavidZemon wrote: »
    Interesting. I wish I could see that first hand. Of course... I don't happen to have any Pentium (4, presumably?) chips laying around to play with :P

    Indeed.
    Basically this laptop is a generation or two after the P4. This fellow is from the period immediately before your system.
  • It could also be that the computer itself is 64-bit but the installed windows just 32-bit.

    I had a couple of acer? laptops from Wallmart configured like that out of the box.

    Mike
    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • msrobots wrote: »
    It could also be that the computer itself is 64-bit but the installed windows just 32-bit.

    I had a couple of acer? laptops from Wallmart configured like that out of the box.

    Mike

    Hello!
    I thought of that at first Mike, also second and third over the activities of this system. However the about system box tells me that it is indeed 64 bit windows on a native system. The <DELETED!> of it is that it is missing those important bits in the processors. At first I thought it was disabled, given the fact that not every system builder remembers to turn on the important bits in a system so I went looking for it in the BIOS for the system. It wasn't there.

    That was the big clew David that the system wasn't an I series processor pair, but really a very late Pentium design.

    However, I can make David's docker ideas work on Linux, when the time comes.

    Besides normally Acer assembles good hardware, but the people who install the OS typically don't do things right.

    So does Dell, but sometimes even they pick an assembly line that's fat fingered.

    Now let's steer the discussion back to the subject.
Sign In or Register to comment.