[PATCH] Some inconsistency in collect2, with respect to gcc and libtool

alled. So, I'm wondering about how to fix that. A simple fix would be tell collect2 that .lo are also object files. Here it is: Mon Jul 10 17:10:09 MET DST 2000 Marc Espie <[EMAIL PROTECTED]> * collect2.c (main): Recognize .lo as object fil

Three problems with libtools

-lutil -R/usr/local/lib -R/usr/local/lib/qt2 -R/usr/X11R6/lib Notice the multiple instances of ICE and SM... this leads to ld taking 90Mb to link the above program... -- Marc Espie |anime, sf, juggling, unicycle, acrobatics, comics... |AmigaOS, OpenBSD, C++, perl, Icon, P

Re: Three problems with libtools

On Tue, Oct 03, 2000 at 04:33:55AM -0200, Alexandre Oliva wrote: > On Oct 2, 2000, Marc Espie <[EMAIL PROTECTED]> wrote: > > > * when invoking gcc to produce shared libraries, always pass pic_flag > > around. > > This can't be done on all platforms. IIRC, o

Re: Three problems with libtools

o effect the change in that jungle of shell-scripts... I ought to give a closer look at the current development version, but having architecture cases all over the place instead of at one more or less central place in the configure section is not that good... -- Marc Espie |

libtool -fpic woes

It's worse than I originally thought. As I started earlier, gcc -shared needs to be passed the code generation flag to work. On multi-libbed systems, things get even worse. Namely, gcc -shared -fpic might give you one path to the system libraries (case in point : -L/usr/lib/gcc-lib/i386-unknown-

libtool, OpenBSD, plugins, large breakage

[Note the crosspost. Yep, this is an utterly messy problem. Yep, I'm fed up of having to deal with a bazillion versions of that huge nightmare called libtool which does never work right on some OSes...] I'm not sure kde makes consistent use of -module and -avoid-version with respect to libtool.