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? > _______________________________________________ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
