Upgrade BoringSSL to pick up OPENSSL_NO_ASM fix against OPENSSL_ARM #5497
Comments
|
This is installing from source, correct? Or are y'all installing from PyPI? What's the output of EDIT: Well, derp, of course you're installing from source - you just said Are you cross-compiling? Or building on the target machine? |
|
I'm not cross compiling because that it just a pain in the ass. So, I am compiling directly on a Raspberry Pi 2, using Slackware 14.1 (because it is armel, not armhf like Raspian or other distros; the target system isn't using armhf). So it is just like compiling on the target system. Here is the output of python -m sysconfig: Paths: Variables: |
|
The only version of grpc that has worked when compiled from source for ARM (for me anyway, with the armel restriction) is 0.11.0b1 (and b0). Newer versions seem to work fine on armhf targets like the Raspberry Pi 2 running Raspian or an Odroid running Ubuntu (both compiled as armhf). It seems that there is trouble in boringssl - like the assembly files (.S files) aren't getting included in the build for the ARM target. Well, it seems that OPENSSL_NO_ASM is defined, so I guess that means no assembly. But still, the functions should still be defined somehow. |
|
So, the issue may or may not be something a bit stranger for those not familiar with some of the hoops we jumped through to have Linux binary distributions in spite of PyPI disallowing such things. Try Also what's the output of |
|
root@slackpi:~# python -c "import platform; print platform.uname()" root@slackpi:~# python -c "import sys; print sys.maxunicode" So I don't think I am using the precompiled binaries, because I thought I saw that you don't have one for UCS2 Python builds on ARM. I did do the above mentioned pip install and still it didn't work. |
|
So much for any of the easy ideas. In all likelihood you're right about the missing parts of BoringSSL, and that could potentially point at us doing something wrong with how we bundle their source and with what compiler flags we're using. It's kind of late where I am... I'll sift through tomorrow and see what comes up. |
|
Well, so much for tomorrow. We're using a 3-month old version of BoringSSL (commit 9f897b2) that doesn't yet respect |
|
Yikes! I wonder if that is the same for gcm_gmult_4bit as well. Dude, go to bed. Thank you for digging in to this. Why did you guys choose to go with boringssl over openssl anyway? I thought I read that Google wasn't advising anyone to include boringssl in their projects in case the api changed. |
|
We can move our BoringSSL version (it's been on my TODO list) - although I We're using BoringSSL because the build system suits us, and we're prepared On Tue, Mar 1, 2016 at 9:52 PM rcordeau [email protected] wrote:
|
|
Ok, that's cool. Not sure how new you want to get with BoringSSL, but I'll pull from the tip of master for that repo and do a build to see how it does. Thanks Craig. |
|
The plan was to start tracking the chromium-stable branch. On Tue, Mar 1, 2016 at 10:09 PM rcordeau [email protected] wrote:
|
|
Ok I'll give that a go. |
|
Craig, what's the automatic fixer and what are the planned updates to wait till next week? Thanks, |
|
The tool in #5494 has a fix option, to automatically make changes to files to ensure the include guards match what we expect (nothing to do with this). The team is currently in an internal commit freeze to give us a chance to stabilize some tests before the final push for 1.0. That freeze is for this week, so we're avoiding doing anything that might affect the stability of tests already passing. |
|
Ok, thanks. I look forward to that merge. |
soltanmm
changed the title
|
Hey Guys, Any update on this bug? I am running into the same issue and is currently blocked continuing my work on an arm computer. |
|
Is there a specific change we want to ensure we're picking up? I'm looking to get the PR out shortly for the upgrade. On Mon, Mar 14, 2016 at 11:46 PM gjoliver [email protected] wrote:
|
|
Anything after commit e6c5402, as far as I can tell. |
|
Is the problem fixed? Ich get the same error, aber fix would be very great |
|
@butterklopsi This has been fixed in PR #6232. |
I have an embedded project running on a Xilinx Zynq, and the linux from Xilinx doesn't do armhf, only armel (soft-fp). With grpc v0.11.0, things worked on the arm with grpc and python. We wanted to upgrade to v0.13 to pickup some bug fixes, and now although we can compile, we get import errors with boringssl. Example:
Anyone have any ideas? I tried cutting out the curve25519 library from boringssl, but that led to another import error for gcm_gmult_4bit. I am kind of at wits end.
Thanks.
The text was updated successfully, but these errors were encountered: