hi Dan,

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
>         needs.

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!

grant.