0

I believe have the same problem as the one described in this question: I'm trying to build an external library which seems to be searching for libXi.so, while I only have libXi.so.6 in the system folders (in /lib64/).

Specifically, the error I receive is

/opt/rh/devtoolset-8/root/usr/libexec/gcc/x86_64-redhat-linux/8/ld: cannot find -lXi

Unfortunately, I do not have sudo access, and cannot follow the same solution proposed in the question linked above: creating a symbolic link which points to libXi.so.6.

I tried creating a symbolic link to libXi.so.6 called libXi.so in a folder that I do have access to, and then added that to LD_LIBRARY_PATH, but that didn't work.

  1. Did I diagnose the problem correctly, or am I missing something?
  2. What are my options, besides reaching out to an administrator?

If it helps, I'm working with CentOS 7.

Thank you.

Edit Additional detail which may be relevant: I am building locally a library A, which, as part of its build process, is automatically building its own external dependency B (I'm assuming A comes with the source for B, or A is automatically downloading B). B is the one that requires libXi.so

josh_eime
  • 39
  • 5
  • 1
    There are workarounds, but you should really reach out to an administrator. You want them to install the development package for libXi (named `libXi-devel` in RedHat-family Linuxes such as CentOS). And if that one is missing then there may be others you need, too. – John Bollinger Sep 21 '21 at 03:53

1 Answers1

2

I tried creating a symbolic link to libXi.so.6 called libXi.so in a folder that I do have access to, and then added that to LD_LIBRARY_PATH, but that didn't work.

The LD_LIBRARY_PATH is searched by the loader at runtime (once the program is linked). You don't have a problem at runtime, you have a problem at (static) link time.

Assuming you have access to $HOME and created a symlink like so:

ln -s /lib64/libXi.so.6 ~/libXi.so

you can use that symlink to link your program like so:

gcc main.o ... -L$HOME -lXi ...

Alternatively you should be able to use /lib64/libXi.so.6 directly to perform the link, like so:

gcc main.o ... /lib64/libXi.so.6 ...

Update:

I am installing a library A, which, as part of its build process, is automatically building its own external dependency B. B is the one which requires libXi.so.

The correct solution for this case is to figure out which package libXi.so.6 comes from, and install development version of that package (which will contain the proper libXi.so symlink).

It's surprising that the B dependency builds without libXi headers installed.

Unfortunately, I do not have sudo access, and cannot follow the same solution

You have to either work with the system admin to get packages you need to develop on this system, or you need to develop on a different system (perhaps a VM, or a docker container), on which you do have admin privileges.

If you aren't willing to do that, then your only option is to edit Makefiles.

Employed Russian
  • 199,314
  • 34
  • 295
  • 362
  • My situation is a bit more complicated - I have updated the question to reflect this. I am installing a library A, which, as part of its build process, is automatically building its own external dependency B. B is the one which requires libXi.so. To apply your solution, I would have to go into the makefile / Cmakelists file of A and manually edit it, which is not ideal. Apologies for leaving out this information initially - I didn't think it would make a big difference. – josh_eime Sep 21 '21 at 18:20
  • @josh_eime I've updated the answer. – Employed Russian Sep 22 '21 at 00:14