Bug 13166 - python-rpi-gpio: does not work against aarch64, unintentional side-effect of gcc-10 patch
Summary: python-rpi-gpio: does not work against aarch64, unintentional side-effect of ...
Status: RESOLVED FIXED
Alias: None
Product: buildroot
Classification: Unclassified
Component: Other (show other bugs)
Version: unspecified
Hardware: All Linux
: P5 normal
Target Milestone: ---
Assignee: unassigned
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-08-19 22:12 UTC by Christian Stewart
Modified: 2020-08-23 21:31 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:


Attachments
Removes a faulty patch which caused a "undefined symbol" error at runtime against aarch64 on a Raspberry Pi. (6.48 KB, patch)
2020-08-19 22:31 UTC, Christian Stewart
Details
Fix patch, add runtime test (6.37 KB, patch)
2020-08-20 22:24 UTC, Yann E. MORIN
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Christian Stewart 2020-08-19 22:12:18 UTC
python-rpi-gpio on aarch64 (pi 4):

ImportError: /usr/lib/python3.8/site-packages/RPi/_GPIO.cpython-38-aarch64-linux-gnu.so: undefined symbol: high

There is a patch attached to the package - 

  fixes the "multiple definition of" errors with gcc10

  Signed-off-by: Michael Fischer <mf@go-sys.de>

It changes the "high" variable to be "extern" which might have caused this?
Comment 1 Christian Stewart 2020-08-19 22:20:16 UTC
According to this, originally the submitter tried to disable the warning, but that patch was rejected by the maintainers:

 http://buildroot-busybox.2317881.n4.nabble.com/PATCH-1-1-package-python-rpi-gpio-fix-build-with-gcc-10-x-td261727.html

Then they submitted another with the more deep changes, I wonder, what was so bad about disabling the compiler warning?
Comment 2 Christian Stewart 2020-08-19 22:31:18 UTC
Created attachment 8566 [details]
Removes a faulty patch which caused a "undefined symbol" error at runtime against aarch64 on a Raspberry Pi.
Comment 3 Christian Stewart 2020-08-19 22:32:18 UTC
Here's a patch to fix it by going back to the "disable compiler warning and paper over the problem" approach, not sure if the maintainers will like it, but at least it fixed the problem for me in the short term.
Comment 4 Yann E. MORIN 2020-08-20 21:09:45 UTC
(In reply to Christian Stewart from comment #1)
> I wonder, what was so bad about disabling the compiler warning?

Because duplicate symbols are a source for bugs. If we just add the -fcommon
option, this indeed hides the warning away, but the problematic code will not
get fixed, and we will have to carry that option ad libitum.

Instead, we want patches that fixes those warnings, so those patches are sent
to the corresponding upstreams, so the packages get fixed, and so we can drop
those patches in a future version bump.

So, I've had a look a deeper look at the patch now, and indeed it is not
complete... I'll follow up with a revised fix. Stay tuned to the ML.
Comment 5 Christian Stewart 2020-08-20 21:30:06 UTC
Thanks Yann. The patch I attached to this bug actually doesn't work anyway, the module still fails at runtime:

  File "usr/lib/python3.8/site-packages/RPi/GPIO/__init__.py", line 23, in <module>
SystemError: Type does not define the tp_name field.

Feel free to send me any patch for testing.
Comment 6 Yann E. MORIN 2020-08-20 22:24:09 UTC
Created attachment 8571 [details]
Fix patch, add runtime test
Comment 7 Yann E. MORIN 2020-08-20 22:25:24 UTC
Christian, care to test the attached patch, please?

The runtime test demonstrates that it is possible to import the
module, but I have no way to test it on real hardware for now...
Comment 8 Christian Stewart 2020-08-20 23:33:15 UTC
Hi Yann, looks to be working perfectly now. Thanks!
Comment 9 Yann E. MORIN 2020-08-23 21:31:21 UTC
Christian, All,

Fixed with commit ae6bd1eb44. Thanks for the report.

Regards,
Yann E. MORIN.