* Get rid of libtool? [was Re: Makefile problems] [not found] ` <87it8mbse7.fsf@tf1.tapsellferrier.co.uk> @ 2002-02-24 16:21 ` Bryce McKinlay 2002-02-24 19:16 ` Brian Jones 2002-02-24 19:35 ` Phil Edwards 0 siblings, 2 replies; 25+ messages in thread From: Bryce McKinlay @ 2002-02-24 16:21 UTC (permalink / raw) To: Nic Ferrier; +Cc: java, gcc Nic Ferrier wrote: >I'm sorry about that. It seems to the fault of my patch. > >I did do a full test (configure, build and install) of the patch on a >fresh check out (with the diff applied). I'm not sure why that didn't >catch the problem. > It is a dependency problem - ie if you touch a source file it will cause everything to be rebuilt rather than just the other files which depend on what you changed. I must admit that, after a frustrating afternoon yesterday trying to figure out silly libjava build problems when I really wanted to do productive gcj hacking, I am sympathetic to RTH's recent suggestion that we get rid of libtool (and automake?) and instead make sure that "gcc -shared" knows how to build a shared library on all the platforms that we care about. I am convinced that this would result in a much more maintainable, transparent, and above all _fast_ build system, in addition to making it easier to implement libjava-specific requirements like package-at-a-time compilation. So, is there anything important that we would lose from such a change? Is there anything that libtool can do that GCC will never be able to do? What platforms do we care about that GCC currently cant build a shared library on (windows perhaps?). regards Bryce. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Get rid of libtool? [was Re: Makefile problems] 2002-02-24 16:21 ` Get rid of libtool? [was Re: Makefile problems] Bryce McKinlay @ 2002-02-24 19:16 ` Brian Jones 2002-02-24 19:35 ` Phil Edwards 1 sibling, 0 replies; 25+ messages in thread From: Brian Jones @ 2002-02-24 19:16 UTC (permalink / raw) To: Bryce McKinlay; +Cc: Nic Ferrier, java, gcc Bryce McKinlay <bryce@waitaki.otago.ac.nz> writes: > So, is there anything important that we would lose from such a change? > Is there anything that libtool can do that GCC will never be able to > do? What platforms do we care about that GCC currently cant build a > shared library on (windows perhaps?). Mingw GCC produces .dll files just fine. Brian -- Brian Jones <cbj@gnu.org> ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Get rid of libtool? [was Re: Makefile problems] 2002-02-24 16:21 ` Get rid of libtool? [was Re: Makefile problems] Bryce McKinlay 2002-02-24 19:16 ` Brian Jones @ 2002-02-24 19:35 ` Phil Edwards 2002-02-24 19:45 ` Alexandre Oliva 1 sibling, 1 reply; 25+ messages in thread From: Phil Edwards @ 2002-02-24 19:35 UTC (permalink / raw) To: Bryce McKinlay; +Cc: Nic Ferrier, java, gcc On Mon, Feb 25, 2002 at 01:04:58PM +1300, Bryce McKinlay wrote: > > I must admit that, after a frustrating afternoon yesterday trying to > figure out silly libjava build problems when I really wanted to do > productive gcj hacking, I am sympathetic to RTH's recent suggestion that > we get rid of libtool (and automake?) and instead make sure that "gcc > -shared" knows how to build a shared library on all the platforms that > we care about. I would fight the removal of automake. It's been awfully darn handy for maintaining libstdc++. (Yes, the currently-required version has its problems with subdirs, but the current automake release seems to have fixed those.) Libtool is completely opaque to me. I wouldn't fight its removal, but I'm not pushing for it either. I also never use it in any of my own projects... [maintainer hat OFF] frankly, the platforms on which libtool is supposed to be magically helpful are platforms which IMHO need to die, and the sooner we abandon them the better. Phil -- If ye love wealth greater than liberty, the tranquility of servitude greater than the animating contest for freedom, go home and leave us in peace. We seek not your counsel, nor your arms. Crouch down and lick the hand that feeds you; and may posterity forget that ye were our countrymen. - Samuel Adams ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Get rid of libtool? [was Re: Makefile problems] 2002-02-24 19:35 ` Phil Edwards @ 2002-02-24 19:45 ` Alexandre Oliva 2002-02-24 19:59 ` Bryce McKinlay 0 siblings, 1 reply; 25+ messages in thread From: Alexandre Oliva @ 2002-02-24 19:45 UTC (permalink / raw) To: Phil Edwards; +Cc: Bryce McKinlay, Nic Ferrier, java, gcc On Feb 25, 2002, Phil Edwards <phil@jaj.com> wrote: > frankly, the platforms on which libtool is supposed to be magically > helpful are platforms which IMHO need to die, and the sooner we > abandon them the better. Yay! HP-UX, AIX, Solaris, Windows, no more! GNU/Linux for everyone! :-) -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{cygnus.com, redhat.com} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist Professional serial bug killer ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Get rid of libtool? [was Re: Makefile problems] 2002-02-24 19:45 ` Alexandre Oliva @ 2002-02-24 19:59 ` Bryce McKinlay 2002-02-24 21:22 ` Alexandre Oliva 0 siblings, 1 reply; 25+ messages in thread From: Bryce McKinlay @ 2002-02-24 19:59 UTC (permalink / raw) To: Alexandre Oliva; +Cc: Phil Edwards, Nic Ferrier, java, gcc Alexandre Oliva wrote: >>frankly, the platforms on which libtool is supposed to be magically >>helpful are platforms which IMHO need to die, and the sooner we >>abandon them the better. >> > >Yay! HP-UX, AIX, Solaris, Windows, no more! > Are you saying that "gcc -shared" does not currently work on these platforms? regards Bryce. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Get rid of libtool? [was Re: Makefile problems] 2002-02-24 19:59 ` Bryce McKinlay @ 2002-02-24 21:22 ` Alexandre Oliva 2002-02-24 22:05 ` Jeff Sturm 2002-02-25 17:00 ` Richard Henderson 0 siblings, 2 replies; 25+ messages in thread From: Alexandre Oliva @ 2002-02-24 21:22 UTC (permalink / raw) To: Bryce McKinlay; +Cc: Phil Edwards, Nic Ferrier, java, gcc On Feb 25, 2002, Bryce McKinlay <bryce@waitaki.otago.ac.nz> wrote: > Alexandre Oliva wrote: >>> frankly, the platforms on which libtool is supposed to be magically >>> helpful are platforms which IMHO need to die, and the sooner we >>> abandon them the better. >>> >> >> Yay! HP-UX, AIX, Solaris, Windows, no more! > Are you saying that "gcc -shared" does not currently work on these > platforms? Nope. I'm saying that there's a bit more than gcc -shared. There are library naming conventions. There are versioning mechanisms that vary from system to system. There are options to get libraries to find one another at run time. There are a lot of small details that, when added up, may turn into enough of a hassle that a lot of libtool's built-in intelligence ends up having to be duplicated, and poorly. The only advantage I see for GCC in keep on using libtool is the abstraction. Abstraction comes with a price, though: it becomes harder to peek into the implementation details. But do people really want to do it? How many of the problems that were blamed on libtool were really bugs in libtool? How many times we didn't have problems just because we were using this package? Is it really worth to ditch it in favor of a more limited solution that will require effort to put in place and maintain? I'm not sure. As I wrote before, I don't oppose this move. But it shouldn't be taken lightly either. There may be some (or a lot) to gain, but I'm pretty sure there's a lot to lose. -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{cygnus.com, redhat.com} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist Professional serial bug killer ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Get rid of libtool? [was Re: Makefile problems] 2002-02-24 21:22 ` Alexandre Oliva @ 2002-02-24 22:05 ` Jeff Sturm 2002-02-24 22:17 ` Phil Edwards ` (2 more replies) 2002-02-25 17:00 ` Richard Henderson 1 sibling, 3 replies; 25+ messages in thread From: Jeff Sturm @ 2002-02-24 22:05 UTC (permalink / raw) To: Alexandre Oliva; +Cc: Bryce McKinlay, Phil Edwards, Nic Ferrier, java, gcc On 25 Feb 2002, Alexandre Oliva wrote: > There are a lot of small details that, when > added up, may turn into enough of a hassle that a lot of libtool's > built-in intelligence ends up having to be duplicated, and poorly. Isn't that happening already for libgcc_s? > The only advantage I see for GCC in keep on using libtool is the > abstraction. But when we need a great deal of control over how the shared lib is built we have to get past the abstraction layer anyway. For any casual, naive attempts to build a shared lib I would wholeheartedly recommend libtool. For specific use like libgcj (and probably libstdc++) it is more debateable. Things I'd like to see (in no particular order): - symbol versioning (libgcj doesn't currently do this, but it could, and probably should). This is platform and tool specific, and to my knowledge libtool doesn't provide any assistance. - real incremental linking (*not* convenience libraries, which are a lousy substitute). - better performance (why couldn't some rules be baked into the makefile rather than evaluated for each compilation?). > Is it really worth to ditch > it in favor of a more limited solution that will require effort to put > in place and maintain? I'm not sure. For libgcj, we could always fall back to static-only on targets where we don't know how to build shared libs. I don't have much confidence that such targets would work even with libtool anyhow. For instance, libgcj assumes public data symbols are exported by default, which certainly isn't true on windows at least. That sort of detail isn't hidden by libtool's abstraction. Jeff ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Get rid of libtool? [was Re: Makefile problems] 2002-02-24 22:05 ` Jeff Sturm @ 2002-02-24 22:17 ` Phil Edwards 2002-02-24 22:24 ` Alexandre Oliva 2002-02-25 9:10 ` Alexandre Oliva 2002-02-25 16:56 ` Richard Henderson 2 siblings, 1 reply; 25+ messages in thread From: Phil Edwards @ 2002-02-24 22:17 UTC (permalink / raw) To: Jeff Sturm; +Cc: Alexandre Oliva, Bryce McKinlay, Nic Ferrier, java, gcc On Mon, Feb 25, 2002 at 12:45:11AM -0500, Jeff Sturm wrote: > On 25 Feb 2002, Alexandre Oliva wrote: > > > The only advantage I see for GCC in keep on using libtool is the > > abstraction. > > But when we need a great deal of control over how the shared lib is built > we have to get past the abstraction layer anyway. > > For any casual, naive attempts to build a shared lib I would > wholeheartedly recommend libtool. For specific use like libgcj (and > probably libstdc++) it is more debateable. I agree here; it seems we spend more time undoing libtool's abstraction than libtool spends adding it. :-) Phil -- If ye love wealth greater than liberty, the tranquility of servitude greater than the animating contest for freedom, go home and leave us in peace. We seek not your counsel, nor your arms. Crouch down and lick the hand that feeds you; and may posterity forget that ye were our countrymen. - Samuel Adams ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Get rid of libtool? [was Re: Makefile problems] 2002-02-24 22:17 ` Phil Edwards @ 2002-02-24 22:24 ` Alexandre Oliva 2002-02-24 23:20 ` Phil Edwards 0 siblings, 1 reply; 25+ messages in thread From: Alexandre Oliva @ 2002-02-24 22:24 UTC (permalink / raw) To: Phil Edwards; +Cc: Jeff Sturm, Bryce McKinlay, Nic Ferrier, java, gcc On Feb 25, 2002, Phil Edwards <phil@jaj.com> wrote: > I agree here; it seems we spend more time undoing libtool's abstraction > than libtool spends adding it. :-) Do you really mean this? I'd like to know of such situations, in which you had to undo libtool's abstraction. That's pretty sad. -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{cygnus.com, redhat.com} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist Professional serial bug killer ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Get rid of libtool? [was Re: Makefile problems] 2002-02-24 22:24 ` Alexandre Oliva @ 2002-02-24 23:20 ` Phil Edwards 2002-02-25 5:36 ` Alexandre Oliva 0 siblings, 1 reply; 25+ messages in thread From: Phil Edwards @ 2002-02-24 23:20 UTC (permalink / raw) To: Alexandre Oliva; +Cc: Jeff Sturm, Bryce McKinlay, Nic Ferrier, java, gcc On Mon, Feb 25, 2002 at 03:17:02AM -0300, Alexandre Oliva wrote: > On Feb 25, 2002, Phil Edwards <phil@jaj.com> wrote: > > > I agree here; it seems we spend more time undoing libtool's abstraction > > than libtool spends adding it. :-) > > Do you really mean this? I'd like to know of such situations, in > which you had to undo libtool's abstraction. That's pretty sad. Mainly I'm referring to the current situation. With regards to libstdc++, I've been lucky enough to be able to leave libtool discussions to others. -- If ye love wealth greater than liberty, the tranquility of servitude greater than the animating contest for freedom, go home and leave us in peace. We seek not your counsel, nor your arms. Crouch down and lick the hand that feeds you; and may posterity forget that ye were our countrymen. - Samuel Adams ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Get rid of libtool? [was Re: Makefile problems] 2002-02-24 23:20 ` Phil Edwards @ 2002-02-25 5:36 ` Alexandre Oliva 0 siblings, 0 replies; 25+ messages in thread From: Alexandre Oliva @ 2002-02-25 5:36 UTC (permalink / raw) To: Phil Edwards; +Cc: Jeff Sturm, Bryce McKinlay, Nic Ferrier, java, gcc On Feb 25, 2002, Phil Edwards <phil@jaj.com> wrote: > On Mon, Feb 25, 2002 at 03:17:02AM -0300, Alexandre Oliva wrote: >> On Feb 25, 2002, Phil Edwards <phil@jaj.com> wrote: >> >> > I agree here; it seems we spend more time undoing libtool's abstraction >> > than libtool spends adding it. :-) >> >> Do you really mean this? I'd like to know of such situations, in >> which you had to undo libtool's abstraction. That's pretty sad. > Mainly I'm referring to the current situation. Aha! So, it turns out that the current situation had nothing at all to do with libtool. The whole issue was on how to pass -shared-libgcc to the link command issued by libtool, and the implications of doing so for other systems. Ok, I'll give you that libtool made this non-optimal by requiring such flag to already be present at its configuration time, which is what confused RTH. IMO, this may be addressed in future releases of libtool. But hey! if this is all you have to count in as `undoing libtool's abstraction', then it seems that you're pretty satisfied with it :-) -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{cygnus.com, redhat.com} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist Professional serial bug killer ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Get rid of libtool? [was Re: Makefile problems] 2002-02-24 22:05 ` Jeff Sturm 2002-02-24 22:17 ` Phil Edwards @ 2002-02-25 9:10 ` Alexandre Oliva 2002-02-26 18:41 ` Jeff Sturm 2002-02-25 16:56 ` Richard Henderson 2 siblings, 1 reply; 25+ messages in thread From: Alexandre Oliva @ 2002-02-25 9:10 UTC (permalink / raw) To: Jeff Sturm; +Cc: Bryce McKinlay, Phil Edwards, Nic Ferrier, java, gcc On Feb 25, 2002, Jeff Sturm <jsturm@one-point.com> wrote: > On 25 Feb 2002, Alexandre Oliva wrote: >> There are a lot of small details that, when >> added up, may turn into enough of a hassle that a lot of libtool's >> built-in intelligence ends up having to be duplicated, and poorly. > Isn't that happening already for libgcc_s? Yup. I find it quite unfortunate, if you ask me. >> The only advantage I see for GCC in keep on using libtool is the >> abstraction. > But when we need a great deal of control over how the shared lib is > built we have to get past the abstraction layer anyway. Like what? > Things I'd like to see (in no particular order): > - symbol versioning (libgcj doesn't currently do this, but it could, and > probably should). This is platform and tool specific, and to my knowledge > libtool doesn't provide any assistance. It goes only as far as letting you pass flags to the linker. It definitely doesn't help you in any way, because symbol versioning is very system-specific. It definitely goes beyond the portable behavior of libraries (static and shared), and libtool doesn't try to get into this business. Which means nothing, if you ask me. The important thing is that it doesn't get in your way to implement this feature. Just like automake doesn't get in your way (contrary to many's claims) when you need custom Makefile rules that don't look like those that automake generates by default. > - real incremental linking (*not* convenience libraries, which are a lousy > substitute). Which of the definitions of incremental linking are you talking about? > - better performance (why couldn't some rules be baked into the makefile > rather than evaluated for each compilation?). That's a possibility, but how much additional garbage are you willing to tolerate in Makefiles? When is it going to be too much? When make starts to run out of command-line space when trying to link libraries? Why not go ahead and skip the overhead of the gcc driver and fold the cc1 && as invocations into the Makefile? Ok, perhaps I'm pushing too much. I'm sympathetic to complains about the performance of libtool. It's dog slow. I know it. Folding stuff into Makefiles might help, but I'm not convinced this would speed it up significantly. Perhaps I'm mistaken. Anyway, IMO, the way to fix this in libtool (whether or not GCC uses it) is to rewrite libtool in a more efficient language. This has been the subject of debates in the libtool mailing lists. The main problem with this rewrite is that any scripting language would become yet another bootstrap requirement for libtool (currently, libtool only depends on Bourne Shell and a small set of portable Unix utilities approved for use in configure scripts); OTOH, any compiled language would require a compiler capable of generating code for the build machine, which is something for which there is no precedent in autoconf, automake and libtool, and that is known to require some shall I say interesting hacks in GCC to get Canadian cross builds right. > For libgcj, we could always fall back to static-only on targets where we > don't know how to build shared libs. And give up dynamic linking entirely. Remember that libtool comes with libltdl, a library that emulates dlopen even in the total absence of dynamic linking. You have to use libtool to link the executables and tell they're going to attempt to dlopen certain libraries, but it works, and I think it's worth it. Of course, one can reinvent the wheel and do it all without libtool. But, again, is it worth it? > For instance, libgcj assumes public data symbols are exported by > default, which certainly isn't true on windows at least. Are you talking of -export-dynamic or something entirely different? Libtool makes -export-dynamic portable. It's enough to link using this option or the -module option, and libtool will know what you mean. > That sort of detail isn't hidden by libtool's abstraction. If you're sure about this, perhaps you meant something else? -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{cygnus.com, redhat.com} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist Professional serial bug killer ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Get rid of libtool? [was Re: Makefile problems] 2002-02-25 9:10 ` Alexandre Oliva @ 2002-02-26 18:41 ` Jeff Sturm 2002-02-26 18:47 ` Richard Henderson 2002-02-27 17:55 ` Alexandre Oliva 0 siblings, 2 replies; 25+ messages in thread From: Jeff Sturm @ 2002-02-26 18:41 UTC (permalink / raw) To: Alexandre Oliva; +Cc: Bryce McKinlay, Phil Edwards, Nic Ferrier, java, gcc On 25 Feb 2002, Alexandre Oliva wrote: > > - real incremental linking (*not* convenience libraries, which are a lousy > > substitute). > > Which of the definitions of incremental linking are you talking about? ld -r > > For instance, libgcj assumes public data symbols are exported by > > default, which certainly isn't true on windows at least. > > Are you talking of -export-dynamic or something entirely different? I'm talking about the dllimport/dllexport mess. Actually the dllexport is solved, I think... it's the dllimport that can't be automated by libtool. Point is, there are characteristics of shared lib implementations that cannot be abstracted away... so is it worth trying? The latter is a problem for libgcj on windows. C/C++ would use __attribute__((dllimport)) to import data members. Java has no such mechanism however. Jeff ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Get rid of libtool? [was Re: Makefile problems] 2002-02-26 18:41 ` Jeff Sturm @ 2002-02-26 18:47 ` Richard Henderson [not found] ` <3C7C4E67.6050001@waitaki.otago.ac.nz> 2002-02-27 17:55 ` Alexandre Oliva 1 sibling, 1 reply; 25+ messages in thread From: Richard Henderson @ 2002-02-26 18:47 UTC (permalink / raw) To: Jeff Sturm Cc: Alexandre Oliva, Bryce McKinlay, Phil Edwards, Nic Ferrier, java, gcc On Tue, Feb 26, 2002 at 08:44:11PM -0500, Jeff Sturm wrote: > On 25 Feb 2002, Alexandre Oliva wrote: > > > - real incremental linking (*not* convenience libraries, which are a lousy > > > substitute). > > > > Which of the definitions of incremental linking are you talking about? > > ld -r Do not do this. Alpha has an architectural limit of 8k got entries per object file. To-date, no single source file has crossed this limit, so it hasn't been a problem. When the objects are left separate until link time, the linker can arrange for each of them to have their entire 8k quota. When you start smashing object files together, the resultant object file still has the 8k per-object limit. Put enough of them together and it's relatively easy to make the link fail. r~ ^ permalink raw reply [flat|nested] 25+ messages in thread
[parent not found: <3C7C4E67.6050001@waitaki.otago.ac.nz>]
* Re: Get rid of libtool? [was Re: Makefile problems] [not found] ` <3C7C4E67.6050001@waitaki.otago.ac.nz> @ 2002-02-27 2:41 ` Richard Henderson 0 siblings, 0 replies; 25+ messages in thread From: Richard Henderson @ 2002-02-27 2:41 UTC (permalink / raw) To: Bryce McKinlay Cc: Jeff Sturm, Alexandre Oliva, Phil Edwards, Nic Ferrier, java, gcc On Wed, Feb 27, 2002 at 04:11:35PM +1300, Bryce McKinlay wrote: > If we did that, what are the chances of hitting this 8k entry limit? Dunno. I'd have to check with a build without current binutils. With current binutils we have available a number of relocs that avoid the use of .got entries. With that, for the entire libgcj, we have 25 .got 0000bad8 000000000084ca88 000000000084ca88 0083ca88 2**3 CONTENTS, ALLOC, LOAD, DATA So 47k of the 64k available to a single object file is used. I suspect that without the new binutils optimizations, we'd be using in the neighborhood of 100k. I guess depending on how you split up the build, you have a decent shot at making it under the limit. > Is there an easy way to get a count of the number of GOT entries > used in a .o? objdump -r foo.o | grep LITERAL | cut -f3- -d' ' | sort -u | wc -l r~ ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Get rid of libtool? [was Re: Makefile problems] 2002-02-26 18:41 ` Jeff Sturm 2002-02-26 18:47 ` Richard Henderson @ 2002-02-27 17:55 ` Alexandre Oliva 1 sibling, 0 replies; 25+ messages in thread From: Alexandre Oliva @ 2002-02-27 17:55 UTC (permalink / raw) To: Jeff Sturm; +Cc: Bryce McKinlay, Phil Edwards, Nic Ferrier, java, gcc On Feb 26, 2002, Jeff Sturm <jsturm@one-point.com> wrote: > On 25 Feb 2002, Alexandre Oliva wrote: >> > - real incremental linking (*not* convenience libraries, which are a lousy >> > substitute). >> >> Which of the definitions of incremental linking are you talking about? > ld -r Libtool already uses this for some features; it would be nice if it could use it for convenience libraries, as I have already suggested before. I didn't know it would cause problems on alpha, though. More complexity :-( >> > For instance, libgcj assumes public data symbols are exported by >> > default, which certainly isn't true on windows at least. >> >> Are you talking of -export-dynamic or something entirely different? > I'm talking about the dllimport/dllexport mess. Actually the dllexport is > solved, I think... it's the dllimport that can't be automated by libtool. Right. That's why libtool requires the library/application to declare it's DLL-compliant with an autoconf macro before it gets into the business of creating DLLs for that library. I heard some people have recently got around this ugly detail of Windows DLLs, though, but I've been too much out of the loop to tell for sur > Point is, there are characteristics of shared lib implementations that > cannot be abstracted away... so is it worth trying? Nope, it has to be left up to the user. Which is what libtool does. -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{cygnus.com, redhat.com} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist Professional serial bug killer ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Get rid of libtool? [was Re: Makefile problems] 2002-02-24 22:05 ` Jeff Sturm 2002-02-24 22:17 ` Phil Edwards 2002-02-25 9:10 ` Alexandre Oliva @ 2002-02-25 16:56 ` Richard Henderson 2 siblings, 0 replies; 25+ messages in thread From: Richard Henderson @ 2002-02-25 16:56 UTC (permalink / raw) To: Jeff Sturm Cc: Alexandre Oliva, Bryce McKinlay, Phil Edwards, Nic Ferrier, java, gcc On Mon, Feb 25, 2002 at 12:45:11AM -0500, Jeff Sturm wrote: > On 25 Feb 2002, Alexandre Oliva wrote: > > There are a lot of small details that, when > > added up, may turn into enough of a hassle that a lot of libtool's > > built-in intelligence ends up having to be duplicated, and poorly. > > Isn't that happening already for libgcc_s? No. The rules for building libgcc_s are quite simple, and are completely contained within one single makefile rule, which is brought in from some target-specific makefile fragment. The problems we're having with libgcc_s are philosophical wrt how it should be partitioned and used. There are zero problems with the actual construction of the library. r~ ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Get rid of libtool? [was Re: Makefile problems] 2002-02-24 21:22 ` Alexandre Oliva 2002-02-24 22:05 ` Jeff Sturm @ 2002-02-25 17:00 ` Richard Henderson 2002-02-27 18:06 ` Alexandre Oliva 1 sibling, 1 reply; 25+ messages in thread From: Richard Henderson @ 2002-02-25 17:00 UTC (permalink / raw) To: Alexandre Oliva; +Cc: Bryce McKinlay, Phil Edwards, Nic Ferrier, java, gcc On Mon, Feb 25, 2002 at 12:59:18AM -0300, Alexandre Oliva wrote: > How many of the problems that were blamed on libtool were really bugs > in libtool? How many times we didn't have problems just because we > were using this package? Is it really worth to ditch it in favor of > a more limited solution that will require effort to put in place and > maintain? How many people can fix problems with libtool when they occur? How many people can fix problems with make when they occur? At present I believe the answer to the first question is "one". You are the only person I'm aware of that works on gcc that knows how to figure out what's happening when something goes wrong with libtool. Note that this is immaterial to whether or not it is libtool that is at fault -- one must still track down the cause, which means understanding how libtool works. On the other hand there are many people on this list that can figure out what to do with a plain Makefile that has target specific fragments spliced in at configure time. Having a single person at that sort of bottleneck is a maintainence problem itself. If you were to be hit by a bus tomorrow (providence forfend) we would either have to spend uncounted hours figuring out how libtool works, or replace it entirely. And I suspect the later would take less time. r~ ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Get rid of libtool? [was Re: Makefile problems] 2002-02-25 17:00 ` Richard Henderson @ 2002-02-27 18:06 ` Alexandre Oliva 2002-02-27 20:17 ` Albert Chin 2002-02-28 0:02 ` Marc Espie 0 siblings, 2 replies; 25+ messages in thread From: Alexandre Oliva @ 2002-02-27 18:06 UTC (permalink / raw) To: Richard Henderson; +Cc: Bryce McKinlay, Phil Edwards, Nic Ferrier, java, gcc On Feb 25, 2002, Richard Henderson <rth@redhat.com> wrote: > How many people can fix problems with libtool when they occur? Err... Zero? :-) Oh, you meant after they occur. Perhaps half a person :-) > How many people can fix problems with make when they occur? Other than the maintainers of make? How many people understand the implications involved with creating libraries and linking with them such that they can be used properly in the build tree (such that you can test before installing being assured that you're not testing against a previously-installed version of the library by accident) and the install tree (such that programs won't search back in say /tmp/gcc-build, where hackers could place their version of libgcc_s.so and escalate privileges whenever other users use gcc)? Libtool takes care of that, and that's *very* important. More important, in fact, than not requiring poor users to set LD_LIBRARY_PATH, if you ask me. I challenge anyone to come up with a simple abstraction of library creation that accomplishes this and does not turn into another barely-maintainable mess like libtool is. In fact, I'd love to be able to retire from this role of sole maintainer of libtool in GCC, but I can't responsibly do this knowing that it will introduce serious security problems in GCC. > At present I believe the answer to the first question is "one". > You are the only person I'm aware of that works on gcc that knows > how to figure out what's happening when something goes wrong with > libtool. Note that this is immaterial to whether or not it is > libtool that is at fault -- one must still track down the cause, > which means understanding how libtool works. I agree. This is a problem. There are 3 ways to fix it: - getting more people to understand libtool :-) - giving up on libtool and duplicating it poorly, probably running into the security problems I mentioned above - getting some people to reimplement (relevant parts of) libtool for GCC such that we no longer depend on a single person > On the other hand there are many people on this list that can > figure out what to do with a plain Makefile that has target > specific fragments spliced in at configure time. And miss some important implications of doing things `the simple way'. > Having a single person at that sort of bottleneck is a maintainence > problem itself. No disagreement here. > If you were to be hit by a bus tomorrow (providence forfend) we > would either have to spend uncounted hours figuring out how libtool > works, or replace it entirely. And I suspect the later would take > less time. I don't disagree it would take less time. But I pity users of not-so-mainstream systems that will pay the price, and those of relatively-mainstream systems that may become victims of hacking due to search paths carelessly encoded into executables or shared libraries that are part of GCC. -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{cygnus.com, redhat.com} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist Professional serial bug killer ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Get rid of libtool? [was Re: Makefile problems] 2002-02-27 18:06 ` Alexandre Oliva @ 2002-02-27 20:17 ` Albert Chin 2002-02-28 0:02 ` Marc Espie 1 sibling, 0 replies; 25+ messages in thread From: Albert Chin @ 2002-02-27 20:17 UTC (permalink / raw) To: Alexandre Oliva Cc: Richard Henderson, Bryce McKinlay, Phil Edwards, Nic Ferrier, java, gcc On Wed, Feb 27, 2002 at 11:02:04PM -0300, Alexandre Oliva wrote: > On Feb 25, 2002, Richard Henderson <rth@redhat.com> wrote: > > > At present I believe the answer to the first question is "one". > > You are the only person I'm aware of that works on gcc that knows > > how to figure out what's happening when something goes wrong with > > libtool. Note that this is immaterial to whether or not it is > > libtool that is at fault -- one must still track down the cause, > > which means understanding how libtool works. > > I agree. This is a problem. There are 3 ways to fix it: > > - getting more people to understand libtool :-) > > - giving up on libtool and duplicating it poorly, probably running > into the security problems I mentioned above > > - getting some people to reimplement (relevant parts of) libtool for > GCC such that we no longer depend on a single person Have the libtool issues been directed to the libtool mailing list where others are watching? Would be nice if GCC used a more recent version of libtool from CVS. -- albert chin (china@thewrittenword.com) ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Get rid of libtool? [was Re: Makefile problems] 2002-02-27 18:06 ` Alexandre Oliva 2002-02-27 20:17 ` Albert Chin @ 2002-02-28 0:02 ` Marc Espie 2002-02-28 0:49 ` Alexandre Oliva 2002-02-28 17:35 ` Phil Edwards 1 sibling, 2 replies; 25+ messages in thread From: Marc Espie @ 2002-02-28 0:02 UTC (permalink / raw) To: aoliva; +Cc: gcc In article <orzo1ucqjn.fsf@free.redhat.lsd.ic.unicamp.br> you write: >On Feb 25, 2002, Richard Henderson <rth@redhat.com> wrote: >> How many people can fix problems with libtool when they occur? >Err... Zero? :-) >Oh, you meant after they occur. Perhaps half a person :-) >> How many people can fix problems with make when they occur? >Other than the maintainers of make? Maintainers, plural. Several makes, lots of maintainers. I've seen people here in the past who can fix bugs in make that don't seem to be make maintainers anyways. As a guy who does both, I'm only tweaking libtool VERY reluctantly. This thing is at least one harder of magnitude LESS maintainable than a Makefile, and probably more. This partly comes from the fact that it is impossible to debug shell scripts of such a size. This also comes from the fact that libtool is incredibly bloated, and does really, really need a complete redesign. The redesign will only happen if someone who cares about it does it. All that people like me will do is say `we shun libtool because it's incredibly bloated and badly need a redesign, and our life is currently much easier without it anyways'. Out of the auto-suite, I can live with automake and its quirks, I can live with autoconf and its quirks, heck, I can live with cygnus-configure and its quirks... and I could very well live without libtool. Okay, this looks like highly flammable material, but think about it. I'm reasonably certain I'm alone in thinking like this. Do you want libtool to go on ? stop being blind to its issues. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Get rid of libtool? [was Re: Makefile problems] 2002-02-28 0:02 ` Marc Espie @ 2002-02-28 0:49 ` Alexandre Oliva 2002-02-28 17:35 ` Phil Edwards 1 sibling, 0 replies; 25+ messages in thread From: Alexandre Oliva @ 2002-02-28 0:49 UTC (permalink / raw) To: Marc Espie; +Cc: gcc On Feb 28, 2002, Marc Espie <espie@quatramaran.ens.fr> wrote: > As a guy who does both, I'm only tweaking libtool VERY reluctantly. > This thing is at least one harder of magnitude LESS maintainable than > a Makefile, and probably more. Certainly more. It's a horrible mess. I'm the first to admit it, because I happen to know it pretty well. I won't deny it. What gets me annoyed is when people say `hey, let's throw all this effort away and reinvent it poorly' or `hey, building shared libraries properly is easy, why do I have to use this junk'. Neither of these assertions are useful. If people find libtool unmaintainable, instead of criticizing it or threatening to replace it, why don't they volunteer to re-do libtool in a more maintainable way? Then we'd have more people with a reasonable understanding of this difficult business of abstracting away properties of static and shared libraries. But perhaps that's not what most people want. Most people wish creating libraries was trivial. Well, with libtool, it is. Without it, you soon end up in a twisty maze of failures on all sorts of different systems, or limit yourself to just a few OSs, for the despair of users of the others. And soon it is discovered that it isn't that simple, and that there are serious problems with the simple way of doing things, and then comes the choice of either living with the problems or cluttering further the build system. I agree libtool in its current implementation is not ideal. But I'm convinced its interface is very sane. I'd love to have cooperation to re-implement it properly, preferably from people interested in GCC such that we wouldn't have to rely on me as a single point of failure. But it's not going to be easy, just because building libraries portably and managing their inter-dependencies is not easy. I wish it were, and I'd love to be proved wrong. But I'm pretty sure I won't. > This also comes from the fact that libtool is incredibly bloated, > and does really, really need a complete redesign. > The redesign will only happen if someone who cares about it does it. I disagree. Its design is very good (thanks Gord!). It's the implementation that sucks. > All that people like me will do is say `we shun libtool because it's > incredibly bloated and badly need a redesign, and our life is currently > much easier without it anyways'. Sure, let's go back to static libraries alone, then introduce shared libstdc++ on a handful of platforms, then get to libjava and find out that it's indeed not easy to get the multiple libraries it relies on linked together properly. But then it will be too late. > I'm reasonably certain I'm alone in thinking like this. Do you want > libtool to go on ? stop being blind to its issues. I'm not being blind. I do see what's going on, but there's little I can do about it. I can't do it all by myself, and those who are interested in shared libraries don't appear to be interested in helping get libtool re-implemented properly. So what can I do? :-( -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{cygnus.com, redhat.com} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist Professional serial bug killer ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Get rid of libtool? [was Re: Makefile problems] 2002-02-28 0:02 ` Marc Espie 2002-02-28 0:49 ` Alexandre Oliva @ 2002-02-28 17:35 ` Phil Edwards 1 sibling, 0 replies; 25+ messages in thread From: Phil Edwards @ 2002-02-28 17:35 UTC (permalink / raw) To: Marc Espie; +Cc: aoliva, gcc On Thu, Feb 28, 2002 at 08:35:05AM +0100, Marc Espie wrote: > This thing is at least one harder of magnitude LESS maintainable than ^^^^^^ What a wonderful Freudian slip. The best part is, if spoken aloud by some of my Cincinnati relatives, it would even sound correct. :-) Phil -- If ye love wealth greater than liberty, the tranquility of servitude greater than the animating contest for freedom, go home and leave us in peace. We seek not your counsel, nor your arms. Crouch down and lick the hand that feeds you; and may posterity forget that ye were our countrymen. - Samuel Adams ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Get rid of libtool? [was Re: Makefile problems] @ 2002-07-03 15:41 Nathanael Nerode 2002-12-28 5:08 ` Alexandre Oliva 0 siblings, 1 reply; 25+ messages in thread From: Nathanael Nerode @ 2002-07-03 15:41 UTC (permalink / raw) To: gcc I'd rather not get rid of libtool; I'd rather improve it until it works right. It's actually not a bad tool, but it has the wrong command-line semantics for Makefile purposes. The *purpose* of libtool is to abstract away the differences in shared library generation. Accordingly, you ought to be able to write x.lo: x.c x.h y.h ... libtool $(CC) -c x.c x.o: x.c x.h y.h ... libtool -static $(CC) -c x.c Unfortunately, libtool insists on doing both the static and shared generation at once. This is a problem when writing dependencies, but it's one which small changes to libtool could fix. Then, for linking: libhello.la: foo.lo hello.lo libtool $(LINK) -o libhello.la foo.lo hello.lo libhello.a: foo.o hello.o libtool $(LINK) -o libhello.a foo.o hello.o Again, libtool insists on doing both at once, which makes writing correct, non-redundant dependencies very hard. This is still a problem which could be fixed really easily in libtool. Linking against uninstalled libraries: program-static: main.o libhello.a libtool $(LINK) -o program-static main.o libhello.a program-shared: main.lo libhello.la libtool $(LINK) -o program-shared main.lo libhello.la And again, the problem is that libtool insists on doing both at once. Pretty much the same damn thing happens with install. However, if this one repeated problem was fixed, encoding libtool-related dependencies into Makefiles would be quite straightforward and would work the Way It Is Supposed To. It wouldn't even need to break libtool backward-compatibility, provided it was implemented as libtool options --only-shared and --only-static. Note that with separate rules for shared and static libtool running, and potentially separate arguments to libtool on a per-file basis, it becomes easy to add specific shared-library options which are wanted by a specific library, or indeed to put an entirely custom non-libtool rule for particularly hairy cases. If one subdirectory is always built with a particular unusual set of requirements, it can even have its own libtool. And it will all work out all right. --- On the other hand, the better I understand Automake, the more I HATE it. It makes it waaay easier to generate nasty, stupid dependency problems. It does a poor job of getting dependencies right, and creates makefiles which can't be read and are therefore hard to debug. I don't see an easy way of fixing most of the problems even with a complete rewrite (although some of the functionality could be better implemented with a few command-line enhancements to 'make'... but that's a complicated other story). Most of the really irritating repetitive stuff which automake abstracts away can be better done using pattern rules, or 'autogen' if you want to work in terrible makes. Most of the other stuff it abstracts away can only *be* abstracted away correctly 80% of the time, which leads to endless problems. An example of this is the way *Automake* uses libtool. Not libtool itself, but the way automake uses it. Automake also makes massive use of Makefile macros, which are a known and proven way to make Makefiles lots slower. I would support any movement to dump automake; it seems to help people create bad Makefiles. --Nathanael ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Get rid of libtool? [was Re: Makefile problems] 2002-07-03 15:41 Nathanael Nerode @ 2002-12-28 5:08 ` Alexandre Oliva 0 siblings, 0 replies; 25+ messages in thread From: Alexandre Oliva @ 2002-12-28 5:08 UTC (permalink / raw) To: Nathanael Nerode; +Cc: gcc [Catching up on a lot of old Nathan's e-mail] On Jul 3, 2002, Nathanael Nerode <neroden@doctormoo.dyndns.org> wrote: > I'd rather not get rid of libtool; I'd rather improve it until it works > right. It's actually not a bad tool, but it has the wrong command-line > semantics for Makefile purposes. The *purpose* of libtool is to > abstract away the differences in shared library generation. Actually, it's to abstract away the differences in library generation, be it shared or static. That's why something like: > x.lo: x.c x.h y.h ... > libtool $(CC) -c x.c > x.o: x.c x.h y.h ... > libtool -static $(CC) -c x.c doesn't make sense. You're exposing the fact that there are static and shared libraries and, in case the user configures --disable-static, you lose. > libhello.la: foo.lo hello.lo > libtool $(LINK) -o libhello.la foo.lo hello.lo > libhello.a: foo.o hello.o > libtool $(LINK) -o libhello.a foo.o hello.o You can do something like this, except that you'll have to use a different filename for the non-libtool object files. Personally, I find it a mistake that libtool creates non-PIC object files outside .libs. They should be hidden, just like everything else, and it would catch this very kind of construct, that could lead to hard-to-debug problems in parallel makes (since make might be tempted to create foo.o by compiling foo.c without libtool while libtool is creating foo.o its own way). Point is, you don't want to use the non-PIC object files from libtool for anything else. If you do, you're abusing the interface, and it may break from under you any time. libtool objects (.lo) and archives (.la) are the only thing you should rely on. You should pretend everything other side effect is not there. > Linking against uninstalled libraries: > program-static: main.o libhello.a > libtool $(LINK) -o program-static main.o libhello.a > program-shared: main.lo libhello.la > libtool $(LINK) -o program-shared main.lo libhello.la > And again, the problem is that libtool insists on doing both at once. Huh? It creates only one copy of a program. You don't have to use libtool objects for it, and, if you use libtool libraries, libtool will use the shared version in the build tree, if available, or the static library otherwise. If you want to prefer static libraries over shared ones, link with -static (!= -all-static, for strictly static linking). You can do both in parallel if you wish. > However, if this one repeated problem was fixed, encoding > libtool-related dependencies into Makefiles would be quite > straightforward and would work the Way It Is Supposed To. Libtool-related dependencies can only involve .lo and .la files. (not counting executables that happen to be linked with libtool, those are not libtool-related dependencies IMHO) > It wouldn't even need to break libtool backward-compatibility, provided > it was implemented as libtool options --only-shared and --only-static. See --tag disable-shared and --tag disable-static in libtool CVS (or the version used by GCC). They do kind of what you want, except they won't create the PIC and non-PIC versions of an object file at the same time and, in fact, it can't be done in certain settings with broken compilers that insist in creating object files in the current directory. Oh, and if you run two of these in parallel, outputting to the same object-file abstraction file (.lo), only one of them will win, so you don't want to do this. > On the other hand, the better I understand Automake, the more I HATE it. > It makes it waaay easier to generate nasty, stupid dependency problems. ?!? > Most of the really irritating repetitive stuff which > automake abstracts away can be better done using pattern rules that you can't use portably anyway. > or 'autogen' if you want to work in terrible makes I still find automake's syntax far cleaner than autogen. After years looking at autogen source files (at rare occasions, I admit), I still fail to find it beautiful :-( > An example of this is the way *Automake* uses libtool. Not libtool > itself, but the way automake uses it. What's the problem with it? It abstracts libtool objects and archives pretty well, and that's all there is to it anyway. -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist Professional serial bug killer ^ permalink raw reply [flat|nested] 25+ messages in thread
end of thread, other threads:[~2002-12-28 7:58 UTC | newest] Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <3C78B3B6.5000303@waitaki.otago.ac.nz> [not found] ` <87it8mbse7.fsf@tf1.tapsellferrier.co.uk> 2002-02-24 16:21 ` Get rid of libtool? [was Re: Makefile problems] Bryce McKinlay 2002-02-24 19:16 ` Brian Jones 2002-02-24 19:35 ` Phil Edwards 2002-02-24 19:45 ` Alexandre Oliva 2002-02-24 19:59 ` Bryce McKinlay 2002-02-24 21:22 ` Alexandre Oliva 2002-02-24 22:05 ` Jeff Sturm 2002-02-24 22:17 ` Phil Edwards 2002-02-24 22:24 ` Alexandre Oliva 2002-02-24 23:20 ` Phil Edwards 2002-02-25 5:36 ` Alexandre Oliva 2002-02-25 9:10 ` Alexandre Oliva 2002-02-26 18:41 ` Jeff Sturm 2002-02-26 18:47 ` Richard Henderson [not found] ` <3C7C4E67.6050001@waitaki.otago.ac.nz> 2002-02-27 2:41 ` Richard Henderson 2002-02-27 17:55 ` Alexandre Oliva 2002-02-25 16:56 ` Richard Henderson 2002-02-25 17:00 ` Richard Henderson 2002-02-27 18:06 ` Alexandre Oliva 2002-02-27 20:17 ` Albert Chin 2002-02-28 0:02 ` Marc Espie 2002-02-28 0:49 ` Alexandre Oliva 2002-02-28 17:35 ` Phil Edwards 2002-07-03 15:41 Nathanael Nerode 2002-12-28 5:08 ` Alexandre Oliva
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).