On 14-Jan-09, at 4:48 PM, Nick Guenther wrote:
> 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.
Damn it Apple, why do you have to make our lives so difficult?
I just remembered another undocumented secret of compiling stuff on OS
X. It looks like everyone (ie. other projects and companies) do their
builds on OS X 10.4 because they're forwards-compatible with 10.5. If
we could get a universal PPC/Intel build working on 10.4, we would be
able to have a single OS X package that would work for all of our
users. (History has shown that many OS X users either don't know what
version of OS X they're using nor pay attention to what architecture
they're on, so they download the wrong package.)
>
>
>
>>
>> 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.
>
Awesome. I think I might have remembered why I stopped building Qt as
a framework, see below.
> 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?
>
If you look in /Library/Frameworks, you'll see a bunch of frameworks.
If you have Qt installed, there should be a folder called /Library/
Frameworks/QtGui.framework, and that's a good example to look at. A
framework is to a library as a bundle is to an application. A
framework is just an easy-to-distribute directory that contains a
compiled library along with the necessary development headers.
For example, with the QtGui framework, you'll see the headers located
in:
/Library/Frameworks/QtGui.framework/Headers
and the precompiled dynamic library located in:
/Library/Frameworks/QtGui.framework/Versions/Current
Note that the dynamic library is just called "QtGui" with no extension
inside that directory, but if you run otool -L or otool -hv on it,
you'll see it's just a dylib. So compiling Qt as a framework is still
compiling it as a dynamic library, except it's all packaged up inside
this framework directory now.
This brings me to why I think I started compiling Qt as a regular
shared/dynamic library instead of as a framework. If you compile it as
a framework, the dylibs are buried into all these crazy framework
directories, and my packaging script would have had to dig through
them. None of the other libraries we link/relink against are like
this, and so it just made my life a bit easier when writing the
packaging script to not have to sort through all these directories.
Hope this helps!
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
