[harbour] Is libudev really need to be depricated in harbour?

I was try made Godot Engine compatible with harbour store, but now i have one last error:

Libraries
=========
ERROR [/usr/bin/harbour-gdmaterials] Cannot link to shared library: libudev.so.1
INFO  [/usr/bin/harbour-gdmaterials] Please see our FAQ here: https://harbour.jolla.com/faq#Shared_Libraries
FAILED

udev need for Controller Support in godot engine ( but it possible to rewrite this part to SDL2 only, but dont really want to do this )

You can ask for harbour inclusion of libudev. Maybe it can enter. Ask it at a community meeting for instance.

In the meantime, you can bundle it in your RPM (useless disk space usage but well) for instance (example given for libjpeg and libcairo) by adding:

install -d %{buildroot}/usr/share/%{name}/lib
install -m 644 -p %{_libdir}/libjpeg.so.62 %{buildroot}/usr/share/%{name}/lib/
install -m 644 -p %{_libdir}/libcairo.so.2 %{buildroot}/usr/share/%{name}/lib/

and defining an RPATH for your executable looking into /usr/share/%{name}/lib/.

You need also to add to your spec %define __requires_exclude ^libjpeg.*|libcairo.*$ somewhere to avoid your RPM to require the libraries that have been bundled. And also something like %define __provides_exclude_from ^/usr/share/.*$ to avoid your RPM to provide the bundled libraries.

4 Likes

i know about providing lib in package. But in my case, i has only binary file (godot export template for sailfish os), without any rpath (but it can be modified with patchelf tool). When i export my project in godot, it just pack prebuild binary and resources to RPM, i cant change rpath of binary at this moment ( without some special tool, like patchelf )
so, i have few ways:

  • jolla-harbour allow libudev ( because, i think, it already in every system as standard )
  • rewrite all udev part in godot to SDL2 ( long way, dont have resources for this )
  • every user should patch export template binary, add rpath to /usr/share/<application_name>/lib, then export rpoject ( no one will do this ), and pack project with libudev
  • compile patchelf util for every arch for sailfish os, and add step for patching binary in every build, pack project with libudev ( not so long way, but not easy too )

I’ll pitch for it at the next community meeting, if I can make it.

5 Likes

Just to clarify on one point, is the key aim here to use the Godot Engine in general (in which case it can be built without the need for libudev), or to explicitly build it with peripheral support (in which case the need for libudev is clear)?

Removing udev support would limit the development of cross-platform games. It’s easier to ‘supplement’ event handlers than rip them out. For instance, to add or simulate InputEventScreenTouch.

Presumably udev opens up a can of ‘sailjail worms’?

udev used in godot to support Controllers. And it would be great, if linking to libudev will be allowed in jolla harbour
P.S. its possible to wrtite controllers support with SDL2 API only, but its long way.

There was some good discussion today. @Thaodan mentioned some discussion from flatpak with a similar issue. In short, we probably need a permission. Though I don’t see what that has to do with linking to udev, per se? Here the relevant links.

@pvuorela had summarized:
yea, so on permission side there seem to be multiple problematic details. a) would need to get access to libudev, b) would also need access to the joypad devices but only them, c) the access to the /dev node could be problematic, there’s resource policy handling, eg two apps wanting to use the same device.
compare to e.g. bluetooth keyboard which doesn’t need any permissions and goes over wayland. might be nice if there was some similar wayland protocol for this. did find some preliminary work but that was getting old.

3 Likes

To extend on @Thaodan 's observations:

https://github.com/netblue30/firejail/pull/4209

1 Like

A slightly off-topic comment about external controllers, when using SDL input code in app at least usb and bluetooth controllers have been successfully tested with my work-in-progress OpenLara SailfishOS port.

1 Like

And those are covered by --private-dev where sailjail is concerned?

I haven’t investigated which device nodes it uses for input but at least I have only enabled audio from sailjail so permissions should be quite strict. I will have to ask for strace output from the testers to check the device nodes.

i was add controller support to Quake 2 port ) based on SDL2, and work well too ) (published on openrepos)