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.


> 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


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.

        Mike
> 
> Thanks!
> 
>> openexr, sorry :) looking at the wrong subject in another window :)
>>
>>     Mike
>>
> 
> 


Reply via email to