Subject: Re: OS X pkgsrc fun
To: Dan Winship <danw@NetBSD.org>
From: grant beattie <grant@NetBSD.org>
Date: 09/14/2003 15:56:57
On Sat, Sep 06, 2003 at 04:52:06PM +0000, Dan Winship wrote:
> I worked through a bunch of OS X pkgsrc bugs/issues and need to figure
> out what to do with them now...
> * libtool: 1.4.20010614nb12 doesn't really work that great on
> Darwin. (PRs 20515, 20520, and 21654 are all libtool problems.)
> 1.4.3 works just fine, but I guess there are problems with that
> somewhere else? (C++/KDE or something?) I saw something about
> libtool 1.5, but it looks like that was during the period when
> mail-index.netbsd.org wasn't indexing, because I can't find it
> now. Is the plan to upgrade to 1.5 "soon"? If not, I guess I can
> try to figure out what patches from 1.4.3 our existing libtool
I believe someone was working on libtool 1.5 integration, yes. don't
let this stop you from identifying which fixes we need, though, as I
don't know how far off we are from importing libtool 1.5.
> * _USE_RPATH=no: There are about a zillion places that need to be
> checking _USE_RPATH that aren't. Fixing all of them would be a
> lot of work, especially in packages like freetype2 that actually
> patch RPATH_FLAG into files. Since Darwin is the only
> _USE_RPATH=no platform, it would be a lot simpler to just kludge
> around the problem by setting _OPSYS_RPATH_NAME to "-L" on
> Darwin and killing off _USE_RPATH. ?
I agree that would probably make things easier to maintain.
> * pthread.buildlink2.mk: "-lpthread" on Darwin is a no-op, and
> while there is a libpthread.dylib, there's no
> "libpthread.0.1.dylib" or whatever, so fake-la messes up when
> trying to buildlink it. (PR 20516). I'm attaching a suggested
> patch for this.
this seems reasonable to me.
> * do-shlib-handling: bsd.pkg.mk thinks that ".so" always needs to
> be converted to ".dylib" on Darwin, which isn't quite right;
> shared libraries end in ".dylib", but loadable modules end in
> ".so". But this is easy to fix; it just needs to check if the
> ".so" file is there, and if so, don't rename it to .dylib in the
> PLIST. I'm also attaching a patch for this, but someone who
> understands the code better could probably make a nicer patch.
ah, I missed this when I fixed up some of the dylib handling because I
tested www/ap-mp3, which installs a so named mod_mp3.so which doesn't
match the regex.
your patch for this seems appropriate, since the only way for pkgsrc
to determine whether a .so is a shared library or shared object is
testing its suffix.
> * bsd.buildlink2.mk: Darwin's gcc has a bug in it that makes
> symlinked header files on UFS not work quite right. I filed a
> bug on opendarwin.org, maybe Apple will fix it for Panther.
> Anyway, if we're not buildlinking /usr/include/pthread.h any
> more, then in most cases we should be able to get away with
> using "ln" rather than "ln -s" to populate the buildlink include
> dirs. If not, or as a fallback, we'll have to cp them. Blah.
> Either way, I'm not sure what the clean way to hack up
> bsd.buildlink2.mk to do that on just Darwin is. (Maybe a
> Darwin-only post-buildlink rule?)
gee, that sucks :( I'll leave that one to the buildlink expert(s) ..
hi, Johnny ;-)
I plan on firing up Darwin/x86 under VMware soon<tm>, which will make
it easier (and faster) to hack on pkgsrc/Darwin than using my laptop.
> This message was sent from evolution 1.4.4 built from pkgsrc on OS X.
that is very cool. how many locks hacks^wpatches did you need? ;-) and
if so, we should get them in pkgsrc for all to enjoy!