On Wed, Jan 14, 2009 at 6:17 PM, Albert Santoni <[email protected]> wrote: > > On 14-Jan-09, at 2:34 PM, Nick Guenther wrote: > >> On Wed, Jan 14, 2009 at 4:20 PM, Albert Santoni <[email protected]> wrote: >>> >>> On 14-Jan-09, at 1:01 PM, Nick Guenther wrote: >>> >>>> Why do we need to compile Qt on OS X with --no-framework? Do you have >>>> to do this on Linux and Windows? Getting Qt compiled is the signal >>>> largest stumbling block to getting a Mixxx development environment set >>>> up. If I could hack this out I'd do it so fast. >>> >>> I started doing this because I found packaging was less of a pain in the >>> ass >>> if I was bundling the .dylibs instead of the entire framework folders on >>> OS >>> X. You can compile without this flag, but you may need to edit the >>> SConscript to make it use the Qt in framework form (as opposed to just >>> straight .dylibs). If I remember right, I did originally have the >>> SConscript >>> using Qt as a framework and that code might still be in the SConscript, >>> just >>> commented out. If you want to build packages though, you'll definitely >>> have >>> to edit that create_osx_dmg.sh script that I wrote, and you may run into >>> the >>> same problem I had before that made me switch to --no-framework. (I >>> totally >>> forget what the problem was though...) >>> >> >> Huh, well, okay. I guess I'll try compiling it straight then and see >> where I get. >> >> I'm confused about what OS X bundling entails. I know you can include >> the libs in the .app, but can you also get it to reference system >> libs? > > Well, when you build any app normally on OS X, it dynamically links against > system-wide libs (eg. what's in /usr/lib and /Library/Frameworks). The thing > that's a pain is that this dynamic linking is hardcoded in the binary to > look for those libraries in those paths, as they were when you compiled. To > see what I'm talking about, run "otool -L [filename]" on any of the Qt > dylibs or on the "mixxx" executable after you've compiled it. > > Windows searches an application's current path (eg. C:\Program Files\Mixxx) > for any DLLs first, which makes distribution nice and easy. However, OS X > only looks in the path that was hardcoded into the binary at compile time. > If you want to distribute the required .dylibs (equivalent of DLLs), you > need to run this "install_name_tool" on your binary. On top of that, any > dylibs that link against _other_ dylibs will need to have install_name_tool > run on them as well. This is relevant because Qt uses separate "plugin" > dylibs for png and svg support, and probably some other stuff I'm > forgetting. As you can hopefully imagine now, there's a crapload of > relinking that needs to be done in order to distribute Qt dylibs (and all > the other libraries we bundle with Mixxx). > > >> >> >> This looks relevant: >> http://lists.trolltech.com/qt-interest/2006-10/thread01322-0.html >> and this: >> http://lists.trolltech.com/qt-interest/2008-09/thread00258-0.html, >> particularly the part about 'deployqt'. > > The consensus I see from this thread is that everyone that dynamically links > on OS X some crazy script just like we do. I had to figure a lot of this out > the hard way though. :) > > However, I would be VERY interested to see what static linking is like on OS > X. If we were to simply statically link Mixxx against Qt and all the other > libraries, we wouldn't have to do any crazy relinking and it would hopefully > simplify OS X builds a lot.
http://developer.apple.com/qa/qa2001/qa1118.html "Static linking of user binaries is not supported on Mac OS X." Anyway, dynamic linking is fine. All the libs build dynamically by default, and Qt comes built that way too. My goal here is to reduce the amount of things you have to do to get working on Mixxx. > > Nick, do you want to try to take a crack at this? ^^^ > (Qt and all the other libraries like libsndfile should have configure flags > for building static versions. Try running ./configure --help for more info.) Well, no, but I will keep trying to clean the rest up. I've actually got Mixxx compiled against the frameworks. I just reeneabled the lines you'd commented out and added a new one for QtScript. I'll see if I can get it bundled next. Actually, what is this -framework stuff anyway? ld(1) says " -framework name[,suffix] This option tells the linker to search for `name.framework/name' the framework search path. If the optional suffix is specified the framework is first searched for the name with the suffix and then without (e.g. look for `name.framework/name_suffix' first, if not there try `name.framework/name')." I ran otool -hv on some libs in /usr/lib. I tried it against a .a version and then a .dylib version of the same lib (confirmed they weren't symlinked together too). Both said they were of type MH_MAGIC. So what's a dylib, then? Why is it important to build dylibs? >> Also, what what is mkpackage.pl for? It claims it works on mac but it >> seems more like create_mixxx_dmg.sh does that. Related, here's someone >> who's made up some copypaste build code so that you don't have to make >> the bundle yourself: http://www.scons.org/wiki/MacOSX >> > > mkpackage.pl is from like 5 years ago or something, so I just deleted it > from SVN to make things less confusing. :) > > I looked at that SCons bundle building script, but I don't get it. Why do I > need to do all those crazy SCons calls in order to create a bundle if all I > need to do is copy some files around? I don't see the advantage of doing it > the way they did it, especially since it completely ignores the relinking > thing. Yeah, you're right. I didn't read it the code, I was too quick to want to get it out here. -Nick ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Mixxx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mixxx-devel
