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. 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.) > > > 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. Thanks, Albert ------------------------------------------------------------------------------ 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
