Page MenuHomeFreeBSD

Make dependency on libvulkan.so more specific to fix port issues
AbandonedPublic

Authored by se on Jun 16 2021, 9:08 PM.
Tags
None
Referenced Files
Unknown Object (File)
Mon, Apr 15, 5:07 PM
Unknown Object (File)
Sun, Mar 24, 11:52 PM
Unknown Object (File)
Wed, Mar 20, 12:07 AM
Unknown Object (File)
Feb 26 2024, 2:37 PM
Unknown Object (File)
Jan 3 2024, 1:52 AM
Unknown Object (File)
Dec 25 2023, 3:07 PM
Unknown Object (File)
Dec 20 2023, 3:57 AM
Unknown Object (File)
Dec 14 2023, 7:00 AM
Subscribers

Details

Summary

With electronn ports installed, LIB_DEPENDS with a pattern of libvulkan.so will find /usr/local/share/electron11/libvulkan.so and consider the dependency satisfied.

In order to actually depend on the libvulkan.so provided by the vulkan-loader package, the dependency must be masde more specific.
Since electron provides only a pure libvulkan.so and no libvulkan.so.* files, it suffices to make the ports depend on libvulkan.so.1 to fix the dependency check and to prevent the port build to fail.
This is not an issue when building in a poudriere jail or on a system that does not have electron installed, but building a port with just "make all" in the port's directory should still be supported and easily can.

Test Plan

Apply patch and verify that the dependency works, i.e. does ignore the libvulkan.so provided by the electron package and installs vulkan-loader, if not already available.

I'm adding a few maintainer of affected ports as reviewers to this review.

Diff Detail

Repository
R11 FreeBSD ports repository
Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

se requested review of this revision.Jun 16 2021, 9:08 PM
se created this revision.
  • Looks nop because devel/electron11 installs %%DATADIR%%/libvulkan.so.1 with USE_LDCONFIG=${DATADIR}
  • Why Electron needs its own copies of libEGL, libGLESv2, libvulkan? Maybe those should be prepended with @comment
  • Looks nop because devel/electron11 installs %%DATADIR%%/libvulkan.so.1 with USE_LDCONFIG=${DATADIR}

At least on my system electron11 did only install libvulkan.so (no libvulkan.so.1 or other versioned variant) and that file is not reported by "ldconfig -r".

$ pkg query %b electron11
libvulkan.so
libEGL.so
libGLESv2.so
libvk_swiftshader.so

But I did just notice that electron11 is current while I'm still at electron11 ...
And I do see libvulkan.so.1 in the pkg-plist of electron12 ...

I do agree, for electron12 the proposed diff is a NOP and another solution ought to be found.

But since electron11 works without issue using the bare .so files, it may possible to just omit the .so.1* files from electron12?

I'll add the maintainer of electron12 to the reviewers of this issue.

  • Why Electron needs its own copies of libEGL, libGLESv2, libvulkan? Maybe those should be prepended with @comment

This would at least require adding library dependencies on vulkan-loader etc.

I have started an electron12 build, but that will take quite some time to finish.

se retitled this revision from Make dependency on libvolka.so more specific to fix port issues to Make dependency on libvulkan.so more specific to fix port issues.Jun 17 2021, 7:35 AM

I have built electron12 on my system now, and the sizes of same name private libraries built by that port and by the independent ports providing them are very different:

$ size /usr/local/lib/libEGL.so /usr/local/lib/libGLESv2.so /usr/local/lib/libvulkan.so
   text	   data	    bss	    dec	    hex	filename
 229140	  10416	    136	 239692	  3a84c	/usr/local/lib/libEGL.so
  67744	    560	      0	  68304	  10ad0	/usr/local/lib/libGLESv2.so
 384704	   9884	     80	 394668	  605ac	/usr/local/lib/libvulkan.so

$ size /usr/local/share/electron12/*.so*
   text	   data	    bss	    dec	    hex	filename
  34994	   2344	    820	  38158	   950e	/usr/local/share/electron12/libEGL.so
6481450	 510600	6358000	13350050 cbb4a2	/usr/local/share/electron12/libGLESv2.so
4292229	 277128	 325744	4895101	 4ab17d	/usr/local/share/electron12/libvk_swiftshader.so
 256755	   3768	     80	 260603	  3f9fb	/usr/local/share/electron12/libvulkan.so.1

But only libvulkan.so has got the ".so.1" extension, and I'd guess it could use a plain ".so" as well, as it does for those other private libraries.

While the libvulkan.so from electron11 did not show up in ldconfig -r output, the one from electron12 does:

$ ldconfig -r | grep vulkan
	740:-lvulkan.1 => /usr/local/lib/libvulkan.so.1
	1745:-lvulkan.1 => /usr/local/share/electron12/libvulkan.so.1

This would make ports that have libvulkan.so in LIB_DEPENDS find it in the pre-requisites scan, but also try to link against the electron12 version, if the graphics/vulkan-loader port is not already installed.
While the electron12 version comes later than the vulkan-loader version, it would be linked against programs the need the latter, should the vulkan-loader package be de-installed.

Therefore I'd think that it would be best to remove the ".1" from the electron12 version of libvulkan (and thus go back how it was named in electron11), and to apply the patch suggested in this review.

I have found the following line (of 27 that contain "libvulkan.so.1" in the elcectron12 sources):

src/third_party/vulkan-deps/vulkan-loader/src/BUILD.gn: 
    # Create libvulkan.so.1 on Linux instead of libvulkan.so

So, this has obviously been a change for Linux that we probably do not need.

I'm not sure that the private libvulkan.so needs to be visible to the find-lib.sh script at all - or IOW whether it needs to be registered in such a way that it is not completely private to the electron software.

I'm rebuilding other ports now to test whether electron12 could work with libvulkan.so.1 from the graphics/vulkan-loader port.

This comment was removed by se.

Put back correct patch - I had erroneously uploaded a patch meant for a different review (too many open reviews at a time in different browser tabs ...).

Two ports provide private versions of libvulkan.so.1 now, so the proposed patches to make the ports depending on libvulkan.so.1 from the vulkan-loader port will no longer have any effect.

The electron12 and vscode ports should either use the libraries provided by the vulkan-* ports or at least hide their private versions (i.e. have them not appear in the output of "ldconfig -r" which is used for dependency checks in the ports system).

gerald added a subscriber: gerald.

This says "abandoned" so may not be relevant any longer, but for the benefit of the doubt (and apologies for the late response) I am cool with the emulators/wine* changes should this be the direction we want to go.

I just am not qualified to review the patch as such.