Hi Kean, * Kean Johnston wrote on Wed, Nov 09, 2005 at 10:18:27AM CET: > >Well, I believe the SCOABSPATH is not only ugly, but also broken (from a > >libtool perspective): if you have a package which creates two libraries, > >one depending on the other, your uninstalled library will link against a > >previous installed version, if that exists. While testing, this is > >wrong. > I agree its ugly but its a necessary evil. All the point you raise > about it being generalized are valid, and I will help out as much > as I can to make that happen. But its going to take a while for > 2.0 to be adopted. Meanwhile, I believe a new release of 1.5 is > imminent, and people are likely to upgrade to that, and it will be > around for a while. The problem is, as things currently stand, > libtool will create shared libraries that expose a severe security > flaw.
OK. I'll take the SCOABSPATH, but would rather like it a bit differently, if you agree: The way I understand your intentions, it should suffice if you can decide at configure time about the absoluteness of the paths (rather than at link time). So you could do this instead: if test -z "$SCOABSPATH"; then archive_cmds='bla bla' archive_expsyms_cmds='bla otherbla' else # ... fi which would be at least a lot more readable. Could you or Tim resubmit the patch like this for branch-1-5? Then, when you forward-port to CVS HEAD, leave out the SCOABSPATH part; we shall try to get -allow-absolute-soname working (and can still think about moving the hack forward if that doesn't work out). At the first occurrence of SCOABSPATH, please add a comment that this thingy will not be supported, and that it breaks testing of uninstalled libraries. Would this be ok with you? Cheers, Ralf