OS X: linker not finding QtGui in framework...

OS X 10.6 Snow Leopard
Qt464, local build, carbon. Installed in '/usr/local/Trolltech/Qt-46-carbon'. Qt built as frameworks.
Makefiles built from .pro file.
--------
Building a fairly complex suite of projects - in the final executable of one project, I'm getting this error: "Can't find QtGui.framework/Versions/4/QtGui". Unfortunately, it doesn't list the path to the framework...

It's there, in the install loc lib location. I built a test project using QtGui and it finds it just fine. I've been crawling through the output makefiles on the bad project and noting the -F and -L specs look correct - they're pointing to the correct locations.

I tried copying the frameworks to the /Library/Frameworks system location, just to see if maybe the linker is looking for them there - no dice, same error.


So, I'm a bit stumped on this one - the only thing I can think of is that one (or more) of the pre-built libraries we're linking to has an rpath designation for the Qt libs that is different from ours (seems that shouldn't matter for a link - only execution...) - I'm going through them with otool now to see what's in there...


Any thoughts appreciated.

rickb

Followup: Hmm. I'm noticing the external libs are built as 'universal' - mine are built only as i386. Wonder if that has anything to do with it? Maybe it's looking for the ppc versions of the lib and not finding that... Hate to do yet another build just to find out...

Ok, I tried rebuilding Qt as universal. Same error: "ld: file not found: QtGui.framework/Versions/4/QtGui"

So providing the ppc parts didn't make any difference. I'm really stuck, now.

Someone run into this?

thanks,
rickb
---------------------------------
Followup: Happens building from commandline and from xcode - no difference.

why you need to build Qt? what about using the sdk. I too had many problems with qt builds on mac, finally using sdk for all.

Because it's the only way to support multiple versions of Qt on the Mac.

It built fine, it installs fine, it's in the right place, and a demo project can link to it just fine.
The problem is with this more complex project that brings in a lot of external libs.

I think it's the internal refs in the external dylibs that is causing the problem - I have to go through them all and see what's up with those, I guess.

Voila! It is the embedded rpaths in the external dylibs and frameworks.

I wrote a python tool to straighten those out so they're self-consistent and point to the correct dependencies, and the '<library> not found' error went away.

Now, I only have a small problem with Xerces.... (ptui...)