On Tue, Feb 26, 2008 at 08:25:25PM -0800, Danek Duvall wrote: > On Tue, Feb 26, 2008 at 05:47:06PM -0600, Nicolas Williams wrote: > > > > What ends up in the runpath here by default, anyway? > > > > /usr/lib -- yeah, no runpath should be needed then, right? > > > > BTW, I needed fix_elf_runpath() because libtool was somehow adding > > $SRC/lib/libsqlite3/... to the runpath of libtclsqlite3 (but not to > > libsqlite3). Don't ask me why; I don't know why. > > Because libtool is a pile. But you also say that /usr/lib ends up there > by default, so I'm a bit confused.
You're not kidding. And I'm confused also. I think /usr/lib showed up because it was in LD_OPTIONS (but that didn't override whatever libtool wanted -- it merged with it). Libtool is turning out to be a nightmare. > You might want to ping Stefan Teleman, as he wrestled against libtool for > many weeks in some of the SFW components. I think he managed to win, but I > can't remember now how he did it. It'd be nice if we didn't have to resort > to elfedit to make these changes, since we *are* building from source, > however uncooperative. OK. And if we could put together a guide for others who might follow, then that'd be even better. > In fact, I'll bet if you patched the build process to include the mapfile > stuff, they might actually take that upstream. And even if they didn't, > maintaining the patch to make that happen might be no worse than > maintaining the script to elfedit the scoping in after the fact, however > badass the elfedit-fu might be. I fully intend to send patches upstream. I'd like to keep those real simple though.
