question about OpenSCAD 2015.03 on Snow Leopard, and a home-built libc++ package installer

[Ken Cunningham]

I would indeed have preferred to put libc++ and libc++abi into the app bundle -- but all the other dylibs linked against them were hard-coded to look for these two libraries in the /usr/lib directory. 

So I tried "install_name_tool'ing" all these libraries to redirect them to a bundled copy of libc++ -- but that didn't work out either after one aliquot of patience trying to make it work.

I'd fix all I could find, but there'd always be more called in somehow that looked in /usr/lib. Perhaps I ultimately might have succeeded with that approach with enough recursion and time - but I ultimately went the route to install into /usr/lib instead as it just "wanted it that way" it seemed. And those libraries on SL are maybe good to have anyway, I rationalized...

dylibbundler seemed like it might be an idea -- but would not include any libraries in /usr/lib (reasonably enough, I guess) even if you want them too -- and it also doesn't know how to include frameworks like qt.

Only thing I'm worried about is a new version of libc++ comes out later for SL, and my package overwrites it with an old version... would prefer if that wouldn't happen. Couldn't see that option in packagemaker, tho. Perhaps there's a trick to that.

License, permission to distribute, all that seem OK? The macports-quoted license seemed quite inclusive.

K


> 
> The app on the disk image already contains a number of libraries, like boost, in the Contents/Frameworks directory. Could you put libc++ and libc++abi in there too, thus making an installer that modifies the OS unnecessary?
>