Mike Sullivan wrote:
> Sheng-qi Jiang wrote:
>
>> Hi Mike,
>> Actually I have checked the code in sfwnv gate, there are a couple to
>> fix RPATH, but I found the libraries code under "usr/src/lib" are
>> all not real C++ except this one: libprecpp.so, which also got this
>> path as below,
>>
>> /ws/sfwnv-gate/proto/root_i386/usr/lib> elfdump -d
>> libpcrecpp.so.0.0.0 | grep PATH
>> [7] RUNPATH 0x1f51
>> /usr/lib:/ws/onnv-tools/SUNWspro/SS11/lib/rw7:/ws/onnv-tools/SUNWspro/SS11/lib:/opt/SUNWspro/lib:/usr/ccs/lib:/lib:/usr/lib
>>
>>
>> [8] RPATH 0x1f51
>> /usr/lib:/ws/onnv-tools/SUNWspro/SS11/lib/rw7:/ws/onnv-tools/SUNWspro/SS11/lib:/opt/SUNWspro/lib:/usr/ccs/lib:/lib:/usr/lib
>>
>
>
> yes that's a bug that's being fixed. That is what will happen if you are
> let in with a runpath like this, a bug will be filed soon after I
> deliver the package which is why you want to fix it before integration.
>
> There are many other such bugs.
>
> A bunch more packages in cmd set -norunpath in various ways. Look at
> them.
>
>
OK, understood!
>> And I have tried the method with -norunpath or set LD_FLAGS, but just
>> not work when linking with "CC".
>> A simple manual test:
>>
>> # /opt/SUNWspro/SS11/bin/CC -G -zdefs -nolib -o
>> .libs/libHalf.so.6.0.0 .libs/half.o -lCstd -lCrun -lc -lm -lpthread
>> # elfdump -d .libs/libHalf.so.6.0.0 | grep PATH
>> [7] RUNPATH 0x4d2
>> /opt/SUNWspro/SS11/lib/rw7:/opt/SUNWspro/SS11/lib:/opt/SUNWspro/lib:/usr/ccs/lib:/lib:/usr/lib
>>
>>
>> [8] RPATH 0x4d2
>> /opt/SUNWspro/SS11/lib/rw7:/opt/SUNWspro/SS11/lib:/opt/SUNWspro/lib:/usr/ccs/lib:/lib:/usr/lib
>>
>
>
>
> You're quite right - if you link with -nolib it your test will still
> have the compiler directories in the runpath. However that's because
> this is what nolib does:
>
> {mike_s:yavin:279} /ws/onnv-tools/SUNWspro/SS11/bin/CC -flags | grep
> nolib
> -nolib Same as -xnolib
> -nolibmil Same as -xnolibmil
> -xnolib Do not link with default system libraries
> -xnolibmil Cancel -xlibmil on command line
> -xnolibmopt Cancel -xlibmopt on command line
>
> (well, -nolib now maps to -xnolib).
>
> Perhaps it's worth trying -norunpath instead, which does this:
>
> {mike_s:yavin:280} /ws/onnv-tools/SUNWspro/SS11/bin/CC -flags | grep
> norunpath
> -norunpath Do not build a runtime search path into the
> executable
>
Yes. It comes out that libtool throw out "-norunpath" option, as it's
not an option for "cc".
>
> Without:
>
> {mike_s:yavin:281} /ws/onnv-tools/SUNWspro/SS11/bin/CC -o hello hello.cc
> {mike_s:yavin:282} dump -Lv hello | grep RUN
> [7] RUNPATH
> /ws/onnv-tools/SUNWspro/SS11/lib/rw7:/ws/onnv-tools/SUNWspro/SS11/lib/v8plus:/ws/onnv-tools/SUNWspro/SS11/lib:/opt/SUNWspro/lib/v8plus:/opt/SUNWspro/lib:/usr/ccs/lib:/lib:/usr/lib
>
>
>
> With:
>
> {mike_s:yavin:283} /ws/onnv-tools/SUNWspro/SS11/bin/CC -o hello
> hello.cc -norunpath
> {mike_s:yavin:284} dump -Lv hello | grep RUN
> {mike_s:yavin:285}
>
>
>>
>> That's why I choose patch it to link with "cc" in the previous
>> version (But I also don't love the patch method).
>
> I wouldn't want to link C++ code with cc, I'd rather let CC do the right
> thing so I wouldn't have to worry about patches/compiler upgrades
> hurting me. I think you can stick -norunpath in the right variable and
> it will work. The problem is finding the right variable. And this
> could be one where you'll need to patch something indeed, as perhaps
> something is dropping the -norunpath.
Yeah, I should add a patch to ltmain.sh.
Thanks for your help!
--
Henry Jiang ( Jiang Shengqi )
Tel: +86-10-6267 3941
SWAN: 82941
