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. http://llvm.org/docs/DeveloperPolicy.html#license > 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. _______________________________________________ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
