ORIGIN使用ld的选项

ORIGIN使用ld的选项

本文介绍了构建一个简单的(hello-world-esque)示例,使用$ ORIGIN使用ld的选项-rpath的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

限时删除!!

注意:下面是完整的工作示例。原来的问题如下:



我在使用ld的 -rpath 参数时遇到问题, $ ORIGIN

因为我找不到完整的示例,所以我想我会自己写一个,以便我和其他人可以稍后使用它。一旦我得到它的工作,我会整理它。



我下载该项目




文件结构(构建之前):


    项目/


      src /


        foo.cpp
        main.cpp

      make.sh






project / src / foo.cpp

  
int foo()
{return 3; }

project / src / main.cpp
$ $ p $
$ f $($)

#include< iostream>
int main()
{
std :: cout<< foo()<<的std :: ENDL;
返回0;

project / make.sh code>

  
#制作目录:
mkdir -p -v obj
mkdir -p -v lib
mkdir -p -v run

#构建库:
g ++ -c -o obj / foo.o src / foo.cpp -fPIC
g ++ -shared -o lib / foo.sh obj / foo.o

#生成可执行文件:
g ++ -c -o obj / main。 o src / main.cpp
g ++ -o run / main.run obj / main.o -Wl,-rpath,'$ ORIGIN /../../ lib'-Llib -l:foo.sh
$ / code>






项目目录下运行 make.sh (确保它是可执行的)。




文件结构(建立后):


    项目/


      src /


        foo.cpp
        main.cpp

        obj /


          foo.o
          main.o

        lib /


          foo.so

        运行/


          main.run
          $ b $ b





        run / main.run 现在应该加载<$



        $在执行时,从任何地方执行c $ c> lib / foo.sh
        b $ b

        问题



        目前,这只有部分工作。

        文件编译并链接正常,但运行时无法链接从项目(这是练习的要点)之外的任何目录。



        检查 main.run with readelf -d 显示:

        0x0000000000000001(需要)共享库:[ lib / foo.sh]

        0x000000000000000f(RPATH)库rpath:[$ ORIGIN /../../ lib]
        看起来很接近(我宁愿 [foo.sh] [lib / foo.sh] 但我会稍后解决)。



        AFAICT -Wl中的 $ ORIGIN ,-rpath,'$ ORIGIN /../../ lib'表示 project / run / main.run ,所以这个rpath应该变成 project / lib



        我试过 $ ORIGIN /.. $ ORIGIN /../ lib $ ORIGIN /../.. $ ORIGIN /../../ lib 无效。



        注意:我使用 -l:这需要完整的库文件名(除其他原因外,当所有函数采用相同的名称格式时,使用变量进行脚本更容易)。



        有人知道为什么这不起作用吗?

        或者,有谁知道有一个完整的工作示例?

        解决方案

        There's most of your problem: the / in the name stops the dynamic linker from doing the rpath magic.

        (Your rpath is wrong too. Think about it: from the shell, if you were currently in the directory where your executable is, how would you get to the directory where your library is? Here, you'd need to cd ../lib. So your rpath should be $ORIGIN/../lib.)

        If you built your object as libfoo.so and linked with -Llib -lfoo, the linker would work out what you were intending, and do the right thing. But if you're going to use unusual naming conventions, you'll have to help it out:

          Change the link line for the library to explicitly set the SONAME for your library to just foo.sh:

          g++ -shared -Wl,-soname,foo.sh -o lib/foo.sh obj/foo.o

          Fix the rpath:

          g++ -o run/main.run obj/main.o -Wl,-rpath,'$ORIGIN/../lib' -Llib -l:foo.sh

        It's useful to run ldd main/main.run to see what's going on. In your original failing case, you'll see something like:

            lib/foo.sh (0xNNNNNNNN)
        

        (the lack of any => /some/resolved/path showing that it's not done any path resolution). In the fixed case, you'll see something like:

            foo.sh => /your/path/to/run/../lib/foo.sh (0xNNNNNNNN)
        

        这篇关于构建一个简单的(hello-world-esque)示例,使用$ ORIGIN使用ld的选项-rpath的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

        1403页,肝出来的..

09-06 11:05