On 9/21/06, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
</snip> Thanks for the detailed definitions and notes. They help a lot.
Now, please answer the crucial missing questions: 1) Does the stuff (programs and libraries) you are building in your package depend upon installed libraries that are not yet at their ultimate position?
No.
2) Do any libraries that you depend upon have themselves dependencies that are not yet at their ultimate position?
No.
3) For any library in (1) and (2): are they libtool libraries? If yes, please post the *.la file. In any case (libtool libs or not), please post `objdump -p libfoo.so' for them.
n/a unless I misunderstood and you want the objdump -p of all installed libraries.
Now that you mentioned /some/read-only/dir and /some/read-write/dir, one more question: Can /some/read-write/dir be accessed in the form such as /some/prefix/some/read-only/dir ? If yes, let's define /DESTDIR/ as `/some/prefix' and hence speak only of DESTDIR from now on.
No. I'll ask around to see if such a change to our filesystem can be made, but if not, is there an alternative to DESTDIR?
Just to give a couple more hints why the distinctions are important: imagine that at the time you build your code (and install it into a temporary, let's say DESTDIR, staging tree), there is both a set of good third-party libraries (ones you wish to link against) below $DESTDIR$prefix, and a set of bad third-party libraries below $prefix, then it is important that you link against the good ones. Later, at execution time, imagine that your programs and libraries, and the set of good third-party libraries have been moved to their ultimate position, imagine someone else builds a newer version of your package and installs it below $DESTDIR$prefix. Your programs and libraries below $prefix should continue to work, however: they must not contain run paths pointing to below $DESTDIR. Since the respective old and new set of libraries may just be incompatible for some reason (a newer version; or think about cross- compiling for a different system), the path distinction is fundamentally important for these cases.
I'll have to mull this over to grok it completely, but I think I have the gist of it. Thanks, Noel _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool