Hi all, It has been for a while, but please help review it again, I have added a patch for ltmain.sh to solve both of 64bit link and runpath issue.
The code looks cleaner now :-) . http://cr.opensolaris.org/~henryj/openexr/ Thanks. -- Henry Jiang Sheng-qi Jiang wrote: > 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! >
