-
-
Notifications
You must be signed in to change notification settings - Fork 188
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
lirc-tools
’s default.so
plugin fails to load due to undefined symbol: major
#974
Comments
default.so
plugin fails to load due to undefined symbol: major
lirc-tools
’s default.so
plugin fails to load due to undefined symbol: major
Sorry - away this weekend and skimming your issue for now. The lirc patch that you found that includes When I get back, I'll look more. Great issue write up! |
I'm looking at this again. I think the right thing to do is to send a PR to https://sourceforge.net/projects/lirc/ and then wait for them to make a release so that the Buildroot maintainers can pull it in as a version bump. However, I'm not sure how long that it will take for that patch to get merged or they could even reject it. The most practical thing seems like it would be to create a The other option to try if LiRC isn't being actively maintained is to submit the patch to Buildroot. I'm sure that the Buildroot maintainers will want to see that you tried submitting upstream first so that they're not on the hook for maintaining the patch. The good part is that Buildroot is really actively maintained, so getting a response from them doesn't require waiting as long usually. |
Thank you so much for looking into this! ❤️ I'll try reporting the issue back to LIRC folks (not sure if one can submit a PR to SourceForge projects, I had a quick look and didn't find any obvious way, but will look into it again) and if I don't get a response in a week or two (which seems likely as you mentioned, that project seems anything but alive…), I'll try talking to the Buildroot folks. Thank you again! I think this issue can be closed then, since it ought to be fixed in a different place? |
Thanks for trying with the LIRC and Buildroot folks. I closed the issue, but if you run into a brick wall, I'll accept the patch in https://github.com/nerves-project/nerves_system_br. |
Preface
I’m not sure if this is the right place to report this problem, I’m sorry. I only started playing with Nerves three days ago and am not very skilled at Linux. Not sure if this is something for Nerves to fix or for upstream to fix, or if fixed in upstream, if we can just pull the changes, or something else entirely… I’ll appreciate any guidance as to how to proceed here 🙏
Environment
elixir -v
): Elixir 1.16.2 (compiled with Erlang/OTP 26)mix nerves.env --info
)MIX_TARGET
: minetti_os (custom system based on defaultrpi0
image, available at https://github.com/Cellane/minetti_os)MIX_ENV
: devmay help
Current behavior
After creating a custom system that adds
lirc-tools
into userspace and enables infrared receiving and transmitting, and then alteringconfig.txt
to load a necessary device tree overlay,lirc
fails to load itsdefault
plugin:This seems to be consistent with an issue reported here, showing the same
undefined symbol: major
error message.It seems that the solution might be rather simple (as seen in the comments of the aforementioned issue), but I’m not sure how I’d introduce a custom patch to the custom system…
If I graciously
stealborrow/usr/lib/arm-linux-gnueabihf/lirc/plugins/default.so
from current version of Raspberry Pi OS for Raspberry Pi Zero W and place it inrootfs_overlay/usr/lib/lirc/plugins
(the different path between the two systems is related to LIRC config), everything works perfectly, but I feel like this is somewhat hacky and the proper solution would be to fix the build, not replace the artefact.I tested both receiving and transmitting with this borrowed plugin and it works like a charm.
Expected behavior
lirc-tools
should compile with all of its plugins being ready to be used.The text was updated successfully, but these errors were encountered: