Re: flat namespaces redux

The "-flat_namespace -undefined suppress" can be a severe pain. I usually avoid these flags by adding -no-undefined to LDFLAGS, but this can cause havoc with some packages. Trying to compile GTK-2.0 when -no-undefined has been added everywhere is fun fun fun Perhaps we just have to accept that Dar

(no subject)

> From: Christoph Egger <[EMAIL PROTECTED]> > > Short bug description: I can't link against a framework, because libtool > throughs the needed -framework param away. I hit this problem once and created a patch for it, but it's non-trivial. Even if libtool recognizes it as a LDFLAG, libtool does t

libtool on Darwin

Further to my last posting... Having spent the weekend pre-binding libraries with the aid of libtool, only to discover that the X11 libs aren't prebound (hear me growl)... :-) patch attached, though I'm not recommending it for inclusion into CVS - it's more by way of an FYI: here's the libtool t

libtool on Darwin

Hi y'all, Sorry for being so quiet on this issue. I'm not going to say anything about 1.4.2, since I'm only familiar with CVS. Nice of Jaguar to use bash these days, but I still get a lot of broken tests. I have a couple of fixes at home but I don't know whether they fix causes or symptoms... an

Darwin patches: Take 3

Dear libtoolers, Some patch-work. Stress-tested with GTK-2.0 :-) Please please please - pretty please with (optional) cherries on top - people test this/these patch/es on other operating systems and architectures, because I would really like to stop maintaining my own personal libtool... Regard

Support for Objective-C[++]

I'd like to add in support for Objective-C (*.m) and Objective-C++ (*.mm). I know about the work-around using the suffix rule, but it doesn't handle dependencies... Without having looked in any detail at automake, I'm guessing I may have to add support into libtool (possibly even autoconf) as wel

patching for darwin

The attached patch, and the use of bash rather than zsh, reduces the number of failed tests to one - the last failure being hardcode.test, which I haven't really looked at in any detail. A fix for everybody's favourite darwin bug (the convenience lib. thingy) is included. It's improved from my or

Re: libtool awfully slow on MacOSX?

On Wed, 27 Jun 2001, Tim Van Holder wrote: > > libtool is taking 30-40s to execute on my 366MHz iBook running Mac OS X, > > compared with approx. 2s on my 166MHz x86 running Linux, and I'm pretty > > sure it was even quicker still on my iBook when *that* was running Linux, > > so: > > > > Is it

libtool awfully slow on MacOSX?

libtool is taking 30-40s to execute on my 366MHz iBook running Mac OS X, compared with approx. 2s on my 166MHz x86 running Linux, and I'm pretty sure it was even quicker still on my iBook when *that* was running Linux, so: Is it just me & mine, or is there some reason libtool is very slow on Mac

Re: [ 100049 ] conveniece libraries under darwin?

> Sorry, your patch doesn't apply -- and has no context =(O| > > Please resubmit a patch generated with diff -c', and > supply a ChangeLog entry so that we can evaluate the patch > properly. Patience! Patience! I was getting around to it! Anyway, hysterical outburst over, patch attached again