solution for "Symbol not found: _getentropy" on older mac

[krisgale]

in reference to the closed issues #7532 and #7537 which outlines an inability to compile on older mac's, i have determined this solution:

• use homebrew to install python... this will install the latest version of python in /usr/local/bin/python3
• open Terminal and navigate to the directory in which the python3 binary packaged with esp8266 tools resides, which can be seen in the error output in Arduino IDE... in my case this is /Users/USERNAME/Library/Arduino15/packages/esp8266/tools/python3/3.7.2-post1
• rename that binary to something else:mv python3 __python3
• create a symlink to the binary that homebrew newly installed: ln -s /usr/local/bin/python3 python3
• try to compile, and if successful, rejoice that your old tank of a mac is still very useful indeed

[krisgale]

attn: @infinity-computers-dot-net this may work for you

[infinity-computers-dot-net]

Thank you. But this is something the maintainers should be solving at their end. Nothing else behaves like this. If they require a specific version of Python, they should install it as part of the installation.

(Incidentally, I cannot install a newer python using homebrew, because homebrew doesn't work properly anymore on MacOS El Crapitan. Eventually I will upgrade the OS, but I need to sort a bunch of stuff out first and it's a low priority.)

[krisgale]

your mileage may vary, but this worked for me on a macbook (not-Pro) running 10.11.6

[mcspr]

Is the problem with the pre-packaged python version? Can we change it to something else, compatible for both old an new systems, so we don't break new systems fixing this?

I can see this in the package .json for the boards manager

Arduino/package/package_esp8266com_index.template.json

Lines 199 to 205 in b5f3d1d

	{
	"host": "x86_64-apple-darwin",
	"url": "https://github.com/earlephilhower/esp-quick-toolchain/releases/download/2.5.0-4/python3-macosx-portable.tar.gz",
	"archiveFileName": "python3-macosx-portable.tar.gz",
	"checksum": "SHA-256:01a5bf1fa264c6f04cfaadf4c6e9f6caaacb6833ef40104dfbe953fcdb9bca1c",
	"size": "25494144"
	},

Which follows back to this PR #7348

Actual binary is 3.8, not the 3.7.2 mentioned above, why the difference?
https://github.com/earlephilhower/esp-quick-toolchain/blob/master/blobs/python3-macosx-portable.tar.gz

Should we resort to the same 'placeholder' which Linux version currently uses and just call '/usr/bin/env python3' and hope for the best there's at least python3.8 in the system PATH?

[krisgale]

@mcspr it makes sense to me to assume the system on which a sketch is being compiled has "at least version 3.x" of python installed, and to bark about it not being available or in the path, rather than resulting in this cryptic clue that the included binary won't work.

in my case, my successful build (per the symlink method described) was with /usr/local/bin/python3 version 3.9.9

[infinity-computers-dot-net]

In which case, the project should declare itself as requiring MacOS greater than El Crapitan.

[krisgale]

In which case, the project should declare itself as requiring MacOS greater than El Crapitan.

not really?

[earlephilhower]

IMHO this is a non-issue and requires no change other than requiring an Apple supported OSX version.

OSX 10.11.6 is ~4 years past EOL according to Wikipedia: https://en.wikipedia.org/wiki/MacOS_version_history

In general OS X users did not have Python in their path, or they had it in non-specific places. I think Homebrew put it in one spot, the OSX dev tools put it in another, etc. And we need full paths, so that was a non-starter.

If someone can build a prepackaged portable Python 3 on such an ancient machine, we could swap it out for the one we ship (which I myself compiled on a VM which I can no longer run due to swapping from INTC->AMD) assuming it works for current OSes as well.

[krisgale]

i fail to see the value of including a non-functioning pre-built binary when it's not that big of an ask to require an enduser to install python3 themselves? (think of the skill level required to navigate the morass of concerns surrounding esp8266/esp32 and consider that it would easily be inclusive of "knows enough to install dependencies")

that said, would it be a huge ask to provide a "fix my install" script that can be run once to essentially do what i've described above? it could conceivably run which python3 to locate the precise path of the "actual" python3 binary to use.

[earlephilhower]

The prebuilt binary runs fine for the hundreds of Mac users of this repo today. We initially asked Mac users to install Python but that was quite a problem for many of them. This current solution is plug-and-play, no additional work required for them (or Windows users who also get a portable python installed), and lets us only write 1 script and run it on all supported machines, from RPIs to Macs to Wins to Linuxes...

I suggest, @krisgale, since you feel strongly about this, that you do a documentation PR outlining the steps to get this running on OSX10.

[krisgale]

entirely fair... i understand that i'm an edge-case who wishes to continue operating last-decade's model until it's a pile of fried wiring... but i also know i'm not the only one :)

but i also obviously believe that "cross-platform" should have a broader definition than is the current reality.

[infinity-computers-dot-net]

I don't think it is fair. Expecting the users to fix the software themselves has always seemed absurd to me, and a bit of a cop-out. What would you say if I released Windows software that didn't work on Windows 7? Lots of people still use that.

I'm proud to announce that our software works perfectly well on Windows XP and above; and our Linux version runs on systems as far back as 2013.

[d-a-v]

We, maintainers, are users.

Unfortunately, we don't use mac software.
My case: I opted out from unmaintained-by-design hardware long ago.

Your options:

• install windows or linux on your hardware
• help us fixing the software
• deal with it

We, maintainers, are users.

Expecting the users to fix the software themselves has always seemed absurd to me, and a bit of a cop-out.

[krisgale]

@d-a-v clearly, i chose "deal with it," in my own way :)

[infinity-computers-dot-net]

We, maintainers, are users.

You are users, and also you are maintainers. But not all users are maintainers. Therefore, not all users are responsible for fixing the bugs in the product.

Inevitably, if no user-maintainers do so, the responsibility for fixing the broken product lies with the project owner.

[d-a-v]

Unfortunately, none of the four current maintainers are owner of this repository.
You'll have to get to the owner and file your complaint by yourself.
Or, and instead of constantly moaning, you can help maintainers to fix your issue by making - or trying to make - a fixing pull-request.

[infinity-computers-dot-net]

Yes, because it is totally my job to fix someone else's product. Uhuh. And expecting the developers to fix them is "moaning"? Gotcha.

Maybe I should tell my users that, and see what they say.