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

Ryan Schmidt ryandesign at
Fri Jul 29 03:58:55 PDT 2016

On Jul 28, 2016, at 10:33 PM, Ken Cunningham wrote:

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

Sounds like you've already tried all the things I was going to suggest.

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

I'm not aware of an option for that, though it's been awhile since I looked. You could possibly write a custom preflight script to check the library version of the existing libc++.

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

Yes I think so.

> All of the code in LLVM is available under the University of Illinois/NCSA Open Source License, which boils down to this:
> • You can freely distribute LLVM.
> • You must retain the copyright notice if you redistribute LLVM.
> • Binaries derived from LLVM must reproduce the copyright notice (e.g. in an included readme file).
> • You can’t use our names to promote your LLVM derived products.
> • There’s no warranty on LLVM at all.

More information about the macports-users mailing list