Jim Rees <[EMAIL PROTECTED]> writes: > I hate libtool. Like autoconf, it tries to encapsulate all the machine > dependencies in one place, so that individual applications don't have to > worry about what architecture they are running on. This works fine if > libtool works on the machine you are trying to build for. If it doesn't > work, it can be very difficult to fix. Libtool seems to go out of its > way to confound the application developer, even going so far as to hide > the real libraries from view.
Yeah, that's one of the reasons why I wanted to ask first before going to the work of making a patch. On the other hand, I have to say that libtool takes care of some deeply obscure stuff that I never would have come up with in a million years on platforms that I have no access to. I can try to write shared library rules by hand, but if I do that, I'll be able to give you gcc for Solaris and Linux and then everyone else will be on their own. libtool would cover more platforms by far out of the box. It also has the advantage of taking care of the LD_RUN_PATH mess. On the other hand, shlibafsauthent and shlibafsrpc are already a start on building shared versions of the libraries I was looking at and have some compile lines for different platforms. They don't actually do the right thing at the moment since they don't build the code PIC, but I know how to fix that. I'm not sure what else is missing, though. > I would like to see a libafs.so that contains as much as possible of the > current afs static libraries, and if libtool is the best way to do that > I guess I can look the other way while someone else imports it. The approach I was going to take was to libtoolize libafsauthent and libafsrpc, since those are the new API, the API that should be used by new external applications, and code that's already somewhat self-contained. > Mozilla would be an example of a large application heavily dependent on > shared libraries that builds fine without libtool. Yeah, but Mozilla has way more resources available to develop their build system than we do, to be honest. > Then there is the licensing issue. I assume libtool is GPL. Would we > need to ship libtool itself, or can it, like autoconf, generate some > kind of non-GPL glue that we could ship with OpenAFS? # As a special exception to the GNU General Public License, if you # distribute this file as part of a program that contains a # configuration script generated by Autoconf, you may include it under # the same distribution terms that you use for the rest of that program. It's the same deal as Autoconf. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
