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.
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.
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.
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.
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.
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.
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.
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"
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.
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.
Now let's steer the discussion back to the subject.
I WAS able to get propgcc to compile under the latest debian buster by using this docker.
I couldn't compile the propgcc from the parallax git, or the propeller-gcc from dbets's git with this version of debian due to gccv7?,
(it throws errors and warnings that make the compile fail)
However, if you want to play around with compiling PropGCC, this should make it much more reliable than trying to figure out compatible versions of GCC, since newer versions of GCC (such as what ships in Ubuntu 17.10) throw errors when trying to build PropGCC.
Now let's steer the discussion back to the subject.
I WAS able to get propgcc to compile under the latest debian buster by using this docker.
I couldn't compile the propgcc from the parallax git, or the propeller-gcc from dbets's git with this version of debian due to gccv7?,
(it throws errors and warnings that make the compile fail)
However, if you want to play around with compiling PropGCC, this should make it much more reliable than trying to figure out compatible versions of GCC, since newer versions of GCC (such as what ships in Ubuntu 17.10) throw errors when trying to build PropGCC.
It's a permissions problem. Did you run it with the `-u ...` argument as described in my post? If you did, then I'm really lost... hoping you come back and say "oops!" cause i'm not sure where to go from here otherwise.
Pretty sure i did, copy/pasted... i will run it all again. wait... would using the newest openspin do this? I will re-run it all.
I had to sudo this next command to not get the permission error... you didnt show it... im guessing this one dosen't matter?
:~/Desktop/Side$ docker pull davidzemon/propgccbuilder
Using default tag: latest
Warning: failed to get default registry endpoint from daemon (Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get http://%2Fvar%2Frun%2Fdocker.sock/v1.38/info: dial unix /var/run/docker.sock: connect: permission denied). Using system default: https://index.docker.io/v1/
Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Post http://%2Fvar%2Frun%2Fdocker.sock/v1.38/images/create?fromImage=davidzemon%2Fpropgccbuilder&tag=latest: dial unix /var/run/docker.sock: connect: permission denied
:~/Desktop/Side$ sudo docker pull davidzemon/propgccbuilder
Using default tag: latest
latest: Pulling from davidzemon/propgccbuilder
Digest: sha256:0640d11baa34a6b2e207cf26b2df29f3d5452aef06dbc44b5e245a4f4be1f1c3
Status: Image is up to date for davidzemon/propgccbuilder:latest
And mabee heres why:
:~/Desktop/Side$ docker run -it -u $(id -u):$(id -g) -v `pwd`:`pwd` -w `pwd` davidzemon/propgccbuilder
docker: Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Post http://%2Fvar%2Frun%2Fdocker.sock/v1.38/containers/create: dial unix /var/run/docker.sock: connect: permission denied.
See 'docker run --help'.
So, the first time I ran it as sudo when I saw this error.
So i must fix it without sudo? (fix the denial)
As a temporary solution, you can use sudo to run the failed command as root.
However it is recommended to fix the issue by adding the current user to the docker group:
Run this command in your favourite shell and then completely log out of your account and log back in (if in doubt, reboot!):
sudo usermod -a -G docker $USER
After doing that, you should be able to run the command without any issues. Run docker run hello-world as a normal user in order to check if it works. Reboot if the issue still persists.
Logging out and logging back in is required because the group change will not have an effect unless your session is closed.
rebootin...
All docker commands ran without sudo this time....
I installed docker.io from synaptic so perhaps i was supposed to run that permission. RTFM?
I hadn't thought of that, but certainly makes sense. If you run "id -u" inside a "sudo" command, you'll of course get root's ID. That would do it!
I definitely recommend installing Docker from the deb repositories, so you did the right thing. Unfortunately, there's nothing in the deb package that tells you "hey user! You should add yourself to the docker group with usermod!" so I'll bet you're not the first person to run into this
Comments
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.
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.
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
In my earlier thread, I had that working: https://forums.parallax.com/discussion/comment/1429926/#Comment_1429926
Thanks, David!
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.
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.
Indeed.
Basically this laptop is a generation or two after the P4. This fellow is from the period immediately before your system.
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.
I WAS able to get propgcc to compile under the latest debian buster by using this docker.
I couldn't compile the propgcc from the parallax git, or the propeller-gcc from dbets's git with this version of debian due to gccv7?,
(it throws errors and warnings that make the compile fail)
So thank you for doing this David!
You're quite welcome! Glad I could help!
:~$ dpkg -l | grep gcc | awk '{print $2}' gcc gcc-6 gcc-6-base:amd64 gcc-7 gcc-7-base:amd64 gcc-8 gcc-8-base:amd64 gcc-8-base:i386 gcc-8-multilib gcc-multilib lib32gcc-8-dev lib32gcc1 libgcc-6-dev:amd64 libgcc-7-dev:amd64 libgcc-8-dev:amd64 libgcc1:amd64 libgcc1:i386 libx32gcc-8-dev libx32gcc1 linux-compiler-gcc-7-x86Should i remove something? Or do I need to change some path variable so the proper gcc is used?
I had to sudo this next command to not get the permission error... you didnt show it... im guessing this one dosen't matter?
And mabee heres why:
So, the first time I ran it as sudo when I saw this error.
So i must fix it without sudo? (fix the denial)
Google search... https://techoverflow.net/2017/03/01/solving-docker-permission-denied-while-trying-to-connect-to-the-docker-daemon-socket/
As a temporary solution, you can use sudo to run the failed command as root. However it is recommended to fix the issue by adding the current user to the docker group: Run this command in your favourite shell and then completely log out of your account and log back in (if in doubt, reboot!): sudo usermod -a -G docker $USER After doing that, you should be able to run the command without any issues. Run docker run hello-world as a normal user in order to check if it works. Reboot if the issue still persists. Logging out and logging back in is required because the group change will not have an effect unless your session is closed.rebootin...
All docker commands ran without sudo this time....
I installed docker.io from synaptic so perhaps i was supposed to run that permission. RTFM?
I hadn't thought of that, but certainly makes sense. If you run "id -u" inside a "sudo" command, you'll of course get root's ID. That would do it!
I definitely recommend installing Docker from the deb repositories, so you did the right thing. Unfortunately, there's nothing in the deb package that tells you "hey user! You should add yourself to the docker group with usermod!" so I'll bet you're not the first person to run into this
I had to make a few changes.
I had to tell git not to add CRLF to the files with: git config --global core.autocrlf false
To run the docker system my command was: docker run -it -v d:/propgcc-parent:/propgcc-parent davidzemon/propgccbuilder
My build environment is on my D drive and not C. I also had to go into the whale and set D as shareable.
Anyway after about a half an hour it said the build completed.
Almost painless
Mike