On Tue, Nov 22, 2005 at 09:58:44AM +0000, Ralf Wildenhues wrote: > Sorry for the delay.
thanks for responding. it's good to have a libtool developer in this discussion :) > Jacob Meuser <jakemsr <at> jakemsr.com> writes: > > On Sun, Nov 20, 2005 at 12:25:19AM -0500, Brad wrote: > > > On Sat, Nov 19, 2005 at 09:10:33PM -0800, Jacob Meuser wrote: > > > > On Sat, Nov 19, 2005 at 09:12:36PM -0500, Brad wrote: > > > > > > > > > > > > So whatever the library name is supposed to be, either -lfoo or - > > > > > > lfoo-1.8 is up to the software author, most here roll their eyes at > > > > > > > > > > > > versioned libnames, but we accept them... just don't symlink them. > > > > > > > > > > Exactly, which means not removing the ability to create shared libs > > > > > with > > > > > the -release tag. This is a very bad idea. Just remove the symlinking. > > > > > > > > I strongly disagree. > > > > > > > > for example, we'd get _only_ libldap-2.3.so.8.1. then we'd have to > > > > change every port with -lldap to -lldap-2.3. > > I believe a better way would be to have less libraries with -release > (but that may be me only). that is essentially the current situation in the ports tree. there are several patches to remove the -release flag from libtool invocations in Makefiles. > > > Ports should already do the right thing with pkgconfig and the other > > > mechanisms. If not then they need to be fixed. Removing -release support > > > from libtool is not happening. > > Nope. There are some situations where it is necessary. such as? the patch I proposed only changes library_names_spec on OpenBSD. I wasn't really intending for that to go upstream, anyway ... > > I think this would be very common because of the comment that gets > > put into libtool just above the library_names_spec line: > > > > <<< > > # List of archive names. First name is the real one, the rest are links. > > # The last name is the one that the linker finds with -lNAME. > > >>> > > > > so the -release flag doesn't effectively create "release" named > > libraries anyway, since libtool will always create a symlink without > > the release part to the "release" library. > > Well, because it's a hack in a way. For your decision, it may be helpful > to be aware of another related "hack": > http://lists.gnu.org/archive/html/libtool/2005-07/msg00028.html > > Without any symlinks, this won't work well. I do not know whether Keith > has enabled this in X, but would assume so. It has not yet been integrated > into GNU Libtool, but we would like to do so eventually, given that it can > be made to work on as many systems as possible. interesting. not sure how this would affect OpenBSD. currently, there is no soname_spec in libtool for OpenBSD. SONAME seems to be rarely used in libraries on OpenBSD as well. the -old-abi idea is interesting as well :) > > I can see the value in having, say libfoo-1.0.so... and > > libfoo-2.0.so..., you may want to have both installed, for > > example. but this is not possible if both are trying to > > install libfoo.so... as well, which is what libtool would do. > > Well, but this nothing new. true, Keith even mentioned this issue in the above thread. there is something of a push to use a single libtool in the OpenBSD ports tree. that is, use the libtool from the ports tree for every port that uses libtool. really, OpenBSD support in libtool was not so good until fairly recently, so there are a lot of patches for the different libtool versions the various packages come with. but now that there is a libtool that works pretty well, it is a lot easier to just use that instead of trying to patch the various libtools that come with the various packages. my suggestion was intended to further reduce the number of patches for libtool related issues in the ports tree, nothing more, nothing less. > In any case, however you decide: if you want to see the corresponding change > in upstream Libtool as well, please let us know. Thanks. now that I've thought about it a little more, I can see the value in the -release flag from a developer's perspective. you could have a 1.0 release that you are maintaining, and a 1.1 release that is in development. you would might want to have both installed, and just change the symlink back and forth, assuming you would want backward compatability. while this could be useful from a developer's perspective, it is still a conflict from a packager's perspective. this doesn't seem to be how/why the -release flag is generally used, though. maybe the best solution would be to have an "internal" libtool, that is hacked in ways that would be useful for building ports but may limit overall usability/features, and a "standard" libtool port that does not contain such hacks? I dunno. it's not really my decision anyway ;P > Cheers, > Ralf -- <[EMAIL PROTECTED]>
