0

Try to link against libxxx which is here:

❯ ls -al ~/.local/lib/
total 56292
drwxr-xr-x  2 muse user     4096 Jun 23 23:57 .
drwx------ 11 muse user     4096 Jun 23 23:02 ..
lrwxrwxrwx  1 muse user       40 Jun 23 23:51 libxxx.so -> /home/muse/.local/lib/libxxx.so.0.0.1
-rwxr-xr-x  1 muse user 57622768 Jun 23 23:02 libxxx.so.0.0.1

if I try to open in via shortname (xxx), getting an error:

❯ ld -L~/.local/lib/ -lxxx --verbose | grep -i '~/.local/lib//libxxx.so'
ld: cannot find -lxxx
attempt to open ~/.local/lib//libxxx.so failed

But I can directly access it via full path:

❯ ld ~/.local/lib//libxxx.so
ld: warning: libprotobuf.so.23.1.0, needed by /home/muse/.local/lib//libxxx.so, not found (try using -rpath or -rpath-link)
....
mu5e
  • 61
  • 5
  • 1
    [Some good reading with links to more good reading](https://stackoverflow.com/a/42018118/4581301) – user4581301 Jun 24 '23 at 00:12
  • 1
    It is my belief that you _can_ link directly against a `.so` file, see: https://stackoverflow.com/a/726390/5743288 Is that `~` being expanded properly? See: https://stackoverflow.com/a/7197011/5743288 – Paul Sanders Jun 24 '23 at 00:44
  • @user4581301 why do you think it will look for libxxx.a? if you do -lstdc it will look for so, for example. – mu5e Jun 24 '23 at 01:37
  • Does this answer your question? [Difference between $HOME and '~' (tilde)?](https://stackoverflow.com/questions/11587343/difference-between-home-and-tilde/11587409#11587409) – n. m. could be an AI Jun 24 '23 at 04:37
  • @user4581301, no, you're wrong, you can (and very often do) link directly to a shared library, it's only on Windows where you need a static loader library for shared libraries – Alan Birtles Jun 24 '23 at 05:14

1 Answers1

1

Shells (typically) only interpret ~ as meaning your home directory at the beginning of words. In ld ~/.local/lib/libxxx.so, ~ appears at the beginning of the word, so the shell replaces ~ with /home/muse and the ld program is run with the arguments: ld (argument 0) and /home/muse/.local/lib/libxxx.so (argument 1). ld attempts to open the file and succeeds.

But when you type ld -L~/.local/lib/ -lxxx, the ~ is not at the beginning of a word. The shell doesn't process the argument specially and the ld program is run with arguments ld, -L~/.local/lib/, and -lxxx. Programs other than shells generally do not (and should not) interpret ~ as meaning the home directory; they just interpret it as a normal file name. So the command ld -L~/.local/lib/ -lxxx looks for libxxx.so in the directory ./~/.local/lib/, a subdirectory of the current directory which probably doesn't exist.

The general solution is to use the $HOME variable instead of the ~ shorthand, to tell the shell that you really do intend to expand something in the middle of a word.

ld "-L$HOME/.local/lib/" -lxxx

Your ld might be sufficiently modern to allow -L and the path to appear as separate arguments, in which case

ld -L ~/.local/lib -lxxx       # or
ld -L "$HOME/.local/lib" -lxxx

would also work.

HTNW
  • 27,182
  • 1
  • 32
  • 60