* Howard Chu wrote on Mon, Nov 15, 2004 at 10:29:04PM CET: > Ralf Wildenhues wrote: > >* Gary V. Vaughan wrote on Mon, Nov 15, 2004 at 04:34:49PM CET: > > >>Also, what do we do about -rpath? We still need to encode the > >>runtime path to even the dropped deplib directories so that the > >>same library we linked with is picked up at runtime. > > >Erm, is this not handled in the depending library? (I have no idea, > >really, but I hoped this would be so.) > > This is definitely a sticky problem. We do builds that "install" to a > path that is different from their actual, final destination. I'm finding > that the rpath handling at various stages of a build tries to be too > smart for its own good. E.g., I have a build tree in my home directory > for a number of packages in ~/BLD, the ultimate destination is /opt/foo, > and everything is staged into ~/BLD/opt/foo. For files in the resulting > package that contain embedded RPATH/RUNPATHs, I only want "/opt/foo" > present in the binary, but I find a lot of instances of > "/home/hyc/BLD/opt/foo" that I have to squash by manually relinking.
This sounds to me like a genuine bug in Libtool, *not* a structural limitation that cannot be overcome. Can you be bothered to provide a testcase which exposes this failure? Regards, Ralf _______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
