Re: Avoiding linking with /home/packaging/X/libxx.so

[lumin <cdluminate@gmail.com>]

Hi Andrey Rahmatullin,

> >           NOTE: libsharedlib1 has no SONAME
> If it has no SONAME then this won't work. Shared libraries should have
> SONAMEs (also, where that 1 does come from then?).

Well, upstream doesn't set SONAME, and ..
if I just put .so libs together with executables into into a 
binary package, can I omit the absence of SONAME ?

> > 	[...]
> > 	../lib/libsharedlib.so (0x00007f400a08e000) <--NOTICE
> Is this a problem? ldd resolves paths at the run time.

I didn't know this before.
After build I noticed that:

        $ ldd caffe | grep libcaffe
        libcaffe.so
        => /home/lumin/hdd/caffe/.build_release/tools/./../lib/libcaffe.so (0x00007fb4c8160000)
        
To my surprise after I installed this executable to /usr/bin:

        $ ldd caffe.bin  | grep libcaffe
        libcaffe.so => /usr/bin/./../lib/libcaffe.so
        (0x00007fa36300f000)
        
Now I realized that, this is not a problem ...

> If it has rpath set then you should fix that. Otherwise it's not clear if
> the problem really exists as your example is artificial and doesn't show
> real things.

My problem in the original post was resolved.
And, I'm confused with the meaning of "rpath set ... fix that",
the Makefile of caffe indeed uses many -rpath options, e.g.

        553 $(TOOL_BINS): %.bin : %.o | $(DYNAMIC_NAME)
        554     @ echo CXX/LD -o $@
        555     $(Q)$(CXX) $< -o $@ $(LINKFLAGS) -l$(PROJECT) $(LDFLAGS)
        \
        556         -Wl,-rpath,$(ORIGIN)/../lib
        
Is there any problem with "-rpath" that needs a fix ?

FYI: software caffe is available at:
https://github.com/BVLC/caffe

> > The question is, how to get hello linked to /usr/lib/libsharedlib.so,
> > since in fact that lib is located at $(CUDIR)/../lib/libsharedlib.so?
> There is no such thing. SONAMEs, not paths, are added to DT_NEEDED. If you
> mean rpath that's another question and it depends on your build system,
> among other things.

Got it. Now I know the lib path is not just a static string embedded
into ELFs ... I'm not familiar with ld.so's mechanism.

Thank you :-)

-- 
lumin <CDLuminate@gmail.com>