Package j provides libj.so, but it's not linked or copied into the default linker search path

[subsetpark]

System

• xuname: Void 5.13.9_1 x86_64 GenuineIntel uptodate rrrmFFFF
• package: j-901.f_1

Expected behavior

libj.so is available on the default dynamic linker search path (ie, a system call like dlopen("j") should locate libj.so)

Actual behavior

libj.so is present and functional at /usr/lib64/j/j64/libj.so, but not available in /usr/lib64.

Steps to reproduce the behavior

Attempt to use dynamic linking to access the libj.so file provided in the J distribution.

Here's a minimal C program that demonstrates the difference (obviously, the janet package is installed on my system!):

#include <dlfcn.h>
#include <stdio.h>

int main(int argc, char **argv) {
  void *p = dlopen("libjanet.so", RTLD_NOW);
  printf("Janet DLL pointer: %p\n", p);
  void *q = dlopen("libj.so", RTLD_NOW);
  printf("J DLL pointer: %p\n", q);
}

Here's the execution example on my system:

Desktop [] ⊕ gcc ex.c -ldl                                                                                              
Desktop [] ⊕ ./a.out                                                                                                    
Janet DLL pointer: 0x5561857862c0
J DLL pointer: (nil)

[leahneukirchen]

Problem is we have 3 libj.so, so which one should be used?

[subsetpark]

Presumably the same version that’s selected by the jconsole shim. The version selection is based on the system architecture (I think), so it seems safe to make that choice at install time?

[subsetpark]

Alternately, if we didn't want to make that decision for the user, we could provide a script that did the symlinking and post-install instructions which would point them to the script.

[github-actions]

Issues become stale 90 days after last activity and are closed 14 days after that. If this issue is still relevant bump it or assign it.