If I had to guess, I’d bet that there is some important difference between the .pro files for the qtExamples, and for the demos that come with the qt distribution.
Paul
Yes, it’s something to do with the .pro file. I just did a test, commenting out all the root stuff from HelloCanvas.cxx, and pasting in a simple helloworld bit:
QApplication app(argc, argv);
QPushButton hello("Hello world!");
hello.resize(100, 30);
hello.show();
return app.exec();I then did “make clean;qmake -project;qmake;make” and it builds a nice little hello world program. the ‘qmake -project’ overwrote the existing .pro, and now it builds and runs fine, so it’s something in the .pro that comes with HelloCanvas by default which is causing the trouble.
Paul
In general what you described is a good news. It suggested that your problem is a problem of the correct compilation / linking option to be found and applied yet.
Would be it trouble for you to invoke “diff” command to compare the project files?
[quote]so it’s something in the .pro that comes with HelloCanvas by default which is causing the trouble.[/quote]Sure 
QtRoot project adds the $ROOTSYS/include, ROOT shared libraries, RootCint dictionary genearation if needed. “qmake” is the utility to generate the Makefile. You can apply “diff” to Makefiles as well. C’est la vie, for each platform one needs to customize the project / Makefile. I do not think Mac / Cocoa is an exception. I have to beg a pardon again. I have no Mac to try all of these staff myself. However, I hope “diff” is not too complex utility to manage.
[quote=“fine”]In general what you described is a good news. It suggested that your problem is a problem of the correct compilation / linking option to be found and applied yet.
Would be it trouble for you to invoke “diff” command to compare the project files?
diff file attached.
On another note, I’ve continued to try to clean up the MacHeliosSim.xcodproj file, to remove redundant linker flags, etc. which were dumped in by qmake, and I’m now getting a slightly different error: “dyld: Library not loaded: @rpath/libRIO.so”. The core of the problem seems to be that the executable, once built, cannot find the libraries. I have no idea what the rpath nonsense is all about, and I honestly don’t understand how linking works in Xcode. I’ve tried manually setting linker flags (-lRIO, -lGQt, etc), removing, the adding back the libraries to the project file, and just about everything else that I can think of, but the project stubbornly refuses to behave. The only thing I can think is that that rpath thing indicates that static search paths (to what?!?!?) were burned into the root, qtroot, and qt libraries when they were compiled, so that the binary, when it looks for them, ignores the DYLIB_LIBRARY_PATH environment variable, going after that static path instead, and not finding anything (again, why?!?). I’m way out of my depth here. 
Even without access to a mac, you’re providing a tremendous amount of help, Val. Many thanks. 
Paul
ProFiles.diff (2.08 KB)
[quote=“TraxusIV”]diff file attached.[/quote]Well it is not very useful for me. I knew the difference between the project files. It would be nice to compare the Makefiles each project generates.
Pay your attention to LIBS += $$system(root-config --glibs) -lGQtIt injects the regular ROOT linker flags that can clash with the cocoa flags. I believe the problem you are fighting with is well known for ROOT MacOS users ( just search this forum ). My observation ( from the Win32/X11 side line) that Mac is not too friendly platform to link the application for.
Anyway, what you said sounded for me that there is no problem to communicate with cocoa as soon as C++ QtRoot plugin is concern. The main problem is to convince the ROOT Mac user to provide you a good advice to complete the job.[quote=“TraxusIV”]Even without access to a mac, you’re providing a tremendous amount of help, Val. Many thanks. 
[/quote]You are welcome.
Makefile diffs attached in two different formats (side by side, and single column).
Thanks,
Paul
MakeFiles.diff (21.3 KB)
MakeFiles2.diff (6.48 KB)
[quote=“TraxusIV”]…Makefile diffs attached in two different formats (side by side, and single column). …[/quote]There is some fish 
there:
[code]39c39
< export MACOSX_DEPLOYMENT_TARGET = 10.4
export MACOSX_DEPLOYMENT_TARGET = 10.6[/code]Can you investigate that?
[quote=“fine”][quote=“TraxusIV”]…Makefile diffs attached in two different formats (side by side, and single column). …[/quote]There is some fish there:
[code]39c39
< export MACOSX_DEPLOYMENT_TARGET = 10.4
export MACOSX_DEPLOYMENT_TARGET = 10.6[/code]Can you investigate that?[/quote]
It is not the problem. I built the shell of HelloCanvas (basically just the printf statement) with both the 10.4 and 10.6 target version using the new makefile, and both work. Also, I tried to build the original file (with all the root code) using the original makefile, after changing the target from 10.6 to 10.4, but it crashed durring linking, complaining of not being able to use -rpath except in 10.5 or later.
I really think its something to do with the rpath thing, and the linking of the libraries. Beyond that though, I don’t know. My knowledge of makefiles (and even xcode project file settings) is very limited. I’ve never messed with 3rd party libraries before, so I’m really not sure what I’m doing.
Is it possible that some setting during the build phase of the root and qtroot installations itself is somehow to blame?
Thanks,
Paul
Ok, so I created a brand new c++ project in Xcode. It is a simple HelloWorld program. It built and ran perfectly. Then I added libCint.so to the project, and tried to build it:
dyld: Library not loaded: @rpath/libCint.so
Referenced from: /Users/paulthompson/Documents/Programming/Build Products/Debug/LibraryIncludeTest
Reason: image not found
sharedlibrary apply-load-rules all
Data Formatters temporarily unavailable, will re-try after a ‘continue’. (Cannot call into the loader at present, it is locked.)
So the problem is the libraries themselves, somehow.
Paul
Hello,
I confirm that while Qt examples provided by Nokia run sucessfully both from the Terminal and the Finder, the QtRoot examples only run from the Terminal.
For example, when run from the Finder, HelloCanvas crashes with the following report:
Dyld Error Message:
Library not loaded: libGQt.1.dylib
Referenced from: /Users/sizun/local_sw/qttests/HelloCanvas/HelloCanvas.app/Contents/MacOS/HelloCanvas
Reason: image not found
The reason may be that the “install names” of the QtRoot dynamic libraries are not rpathed (as shown by otool -L HelloCanvas.app/Contents/MacOS/HelloCanvas)
I found 2 ways to work around the problem:
- After building the application, you can copy the missing libraries into the bundle and change some paths:
mkdir -p HelloCanvas.app/Contents/Frameworks
cp -f $QTROOTSYSDIR/lib/libGQt.1.dylib HelloCanvas.app/Contents/Frameworks/libGQt.1.dylib
cp -f $QTROOTSYSDIR/lib/libQtRootGui.1.dylib HelloCanvas.app/Contents/Frameworks/libQtRootGui.1.dylib
install_name_tool -change libGQt.1.dylib @loader_path/../Frameworks/libGQt.1.dylib HelloCanvas.app/Contents/MacOS/HelloCanvas
install_name_tool -change libQtRootGui.1.dylib @loader_path/../Frameworks/libQtRootGui.1.dylib HelloCanvas.app/Contents/MacOS/HelloCanvas
install_name_tool -change libGQt.1.dylib @loader_path/../Frameworks/libGQt.1.dylib HelloCanvas.app/Contents/Frameworks/libQtRootGui.1.dylibThis can also be done from Xcode with Add > New Build Phase > New Run Script Build Phase
- Changing the “install names” of the QtRoot libraries (before building HelloCanvas)
cd $QTROOTSYSDIR/lib
install_name_tool -id @rpath/libGQt.1.dylib libGQt.dylib
install_name_tool -id @rpath/libQtRoot.1.dylib libQtRoot.dylib
install_name_tool -id @rpath/libQtRootGui.1.dylib libQtRootGui.dylib
install_name_tool -change libGQt.1.dylib @rpath/libGQt.1.dylib libQtRoot.dylib
install_name_tool -change libGQt.1.dylib @rpath/libGQt.1.dylib libQtRootGui.dylibI guess the proper fix would be to add some “-install_name @rpath/…” flags in the QtRoot makefiles but I am not familiar with that.
Patrick
[quote=“Patrick”]
I guess the proper fix would be to add some “-install_name @rpath/…” flags in the QtRoot makefiles but I am not familiar with that.
Patrick[/quote]
Yeah, my work on this issue for the past week has mostly been trying to figure out how all this rpath junk works. I have yet to find any step by step guide to adding libraries to an xcode project though, so it’s rather slow going.
[quote=“Patrick”] . . .
I guess the proper fix would be to add some “-install_name @rpath/…” flags in the QtRoot makefiles but I am not familiar with that… . . [/quote]There is no “QtRoot makefile”. There are QMAKE project files. The Makefiles are generated by qmake. There are *.pro files in QtRoot. These files do contain the clause: QMAKE_RPATH= Its meaning is “do not rpath” 
indeed.
The doc.trolltech.com/4.6/qmake-vari … make-rpath says,
[quote]This is used on Unix platforms only.
Is equivalent to QMAKE_LFLAGS_RPATH.[/quote]Who knows whether the MacOS is the UNIX platform from the “qmake” standpoint.
See:
paulf.free.fr/undocumented_qmake.html My guess, the only thing one needs to do is to remove this clause for MacOS case. Can you guys try that ?
See also doc.trolltech.com/4.6/qtmac-as-native.html
[quote=“http://doc.trolltech.com/4.6/qtmac-as-native.html”]Development Tools
Mac OS X developers expect a certain level of interopability between their development toolkit and the platform’s developer tools (for example Visual Studio, gmake, etc). Qt supports both Unix style Makefiles, and ProjectBuilder/Xcode project files by using the qmake tool. For example:
will generate an Xcode project file from project.pro. … [/quote] Please,find the correct solution and send me to committe.
Attached is a patch suggestion for the qtRoot directory, using QMAKE_LFLAGS_SONAME = -Wl,-install_name,@rpath/
Best regards,
Patrick
patch.txt (2.27 KB)
[quote=“Patrick”]Attached is a patch suggestion for the qtRoot directory, using QMAKE_LFLAGS_SONAME = -Wl,-install_name,@rpath/
[/quote]Great. 
Merci beaucoup !!! 
I’ll committee it tonight (or tomorrow night). I need internet to apply your patch. Did it allow building qtExamples against of cocoa without any extra steps?
What about 
qt/inc/rootlibs.pri ? Do we need to change it too 
?
Hi Patrick, I has applied your patch and recreated the tarball.
I would appreciate if you could download it
wget root.bnl.gov/QtRoot/downloads/qtFullRoot.tar.gz
and test . Thank you very much.
Hello,
I managed to build the patched version, build (from a terminal) HelloWord, HelloCanvas, HelloLife, run them (now both from a terminal and from the finder).
I still cannot build any examples from Xcode without first fixing the paths to GQt QtRootGui …, which may have something to do with rootlibs.pri ?
Patrick
I still cannot build any examples from Xcode without first fixing the paths to GQt QtRootGui …, which may have something to do with rootlibs.pri ?..[/quote] Yes, it is possible. rootlibs.pri is to define the default rules to link the Qt application against of QtRoot/Root.
Hello, can you send me a compiled Xcode root example project, if you can, I hope you can send me a copy (625225273@qq.com), appreciate it
Please don’t resurrect topics that are a decade old but open a new topic instead.