This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Problem: Building a Qt project on Mac OS X which links to another project fails during the linker stage with "can't map file, errno=22". For example, I created a new Qt Application project with Netbeans 6.8 RC1 and set it to link to another project, which is a static lib, the output is: [BEGIN] /usr/bin/make -f nbproject/Makefile-Debug.mk SUBPROJECTS= .build-conf /usr/bin/qmake VPATH=. -spec macx-g++ -o qttmp-Debug.mk nbproject/qt-Debug.pro mv -f qttmp-Debug.mk nbproject/qt-Debug.mk /usr/bin/make -f nbproject/qt-Debug.mk dist/Debug/GNU-MacOSX/TestLinkQt g++ -headerpad_max_install_names -arch i386 -o dist/Debug/GNU-MacOSX/TestLinkQt build/Debug/GNU-MacOSX/main.o -F/Library/Frameworks -L/Library/Frameworks ../../Documents/Projects/AltEgo.svn/API/AltEgo/dist/MacOSX-Debug/GNU-MacOSX ../../Documents/Projects/AltEgo.svn/API/AltEgo/dist/MacOSX-Debug/GNU-MacOSX/libaltego.a -framework QtGui -framework Carbon -framework AppKit -framework QtCore -lz -lm -framework ApplicationServices ld: in ../../Documents/Projects/AltEgo.svn/API/AltEgo/dist/MacOSX-Debug/GNU-MacOSX, can't map file, errno=22 collect2: ld returned 1 exit status make[2]: *** [dist/Debug/GNU-MacOSX/TestLinkQt] Error 1 make[1]: *** [.build-conf] Error 2 make: *** [.build-impl] Error 2 BUILD FAILED (exit value 2, total time: 1s) [END] I can fix the linker error by manually editing the makefile (or typing in the g++ command into terminal) with the excess linker paths removed. What I mean is... The Linker flags include: ../../Documents/Projects/AltEgo.svn/API/AltEgo/dist/MacOSX-Debug/GNU-MacOSX and ../../Documents/Projects/AltEgo.svn/API/AltEgo/dist/MacOSX-Debug/GNU-MacOSX/libaltego.a That linker line which includes JUST a path (without the actual libaltego.a lib) causes the linker to fail with errno=22. It looks like Netbean's generation of makefiles is adding an extra path entry for each file to link to, which is the source of the problem. This prevents Netbeans from being used to build Qt apps on Mac OS X where a project is needed to be linked to... as Netbeans keeps generating bad makefiles.
Ok. I see your problem. WORKAROUND: Open "Project Properties" window Click on "..." in Build|Linker|Libraries field Push on "Add Library File ..." button Select *.a file and press Select button Press Ok button Clean and Build project ==> CLEAN SUCCESSFUL (total time: 285ms) /usr/bin/make -f nbproject/Makefile-Debug.mk SUBPROJECTS= .build-conf /usr/bin/qmake VPATH=. -spec macx-g++ -o qttmp-Debug.mk nbproject/qt-Debug.pro mv -f qttmp-Debug.mk nbproject/qt-Debug.mk /usr/bin/make -f nbproject/qt-Debug.mk dist/Debug/GNU-MacOSX/QtApplication_1 g++ -c -pipe -g -gdwarf-2 -arch i386 -Wall -W -DQT_GUI_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/local/Qt4.5/mkspecs/macx-g++ -Inbproject -I/Library/Frameworks/QtCore.framework/Versions/4/Headers -I/usr/include/QtCore -I/Library/Frameworks/QtGui.framework/Versions/4/Headers -I/usr/include/QtGui -I/usr/include -I../CppStaticLibrary_1 -I. -Inbproject -I. -F/Library/Frameworks -o build/Debug/GNU-MacOSX/main.o main.cpp g++ -headerpad_max_install_names -arch i386 -o dist/Debug/GNU-MacOSX/QtApplication_1 build/Debug/GNU-MacOSX/main.o -F/Library/Frameworks -L/Library/Frameworks ../CppStaticLibrary_1/dist/Debug/GNU-MacOSX/libcppstaticlibrary_1.a -framework QtGui -framework Carbon -framework AppKit -framework QtCore -lz -lm -framework ApplicationServices BUILD SUCCESSFUL (total time: 1s)
This workaround does not work with dependent projects which are dylibs. Well, it _does_ allow the projects to link, but then then the Qt app cannot be executed because the dynamic library cannot be found at runtime. The proper solution is for the generated .pro file(s) to not include the excess path info in the "LIBS +=" line. Considering this is high-priority for me, I have been examining the cnd sources from Hg and I will likely fix the bug in the Qt .pro generation code in the next day or so (depending upon my available free time). Once done, I will attach the patch to this bug report. Cheers!
I "fixed" this problem for me and my team locally by: 1) Replacing the existing flags in the <dynamic_library_search> tag with flags="-Wl,-rpath," in "GNU_mac.xml" inside of org-netbeans-modules-cnd (see attached). 2) Adding "QMAKE_LFLAGS += -mmacosx-version-min=10.5" to each Qt project configuration's "Custom Definitions". The latter command forces the linker to only target Mac OS X 10.5 or newer (required for the "-Wl,-rpath," linker option), which seems a pretty safe bet these days. Any patch to the source I would make would involve auto-adding the "QMAKE_LFLAGS += -mmacosx-version-min=10.5" to the generated .pro file, which I am not sure is the right solution in this case... Might be better to add a section to the Qt subsection of the toolchain XML definition file(s) which is read and used to generate the .pro. Hmmm...
Created attachment 92691 [details] MacOS X dynamic linker options fixed.
This problem also exists on Windows, which makes Netbeans 6.8 unusable on Windows for developing Qt applications. I have NOT been able to come up with a work-around for this yet.
Actually, the same fix (patch the MinGW .xml files with "-Wl,-rpath," for the dynamic linker search variable). Should these changes be made to the applicable toolchain XML files so that they can be pushed out with Patch 1?
Dustin, thank you for the patch. It works indeed, but it could potentially have unexpected side effects for non-qt projects. I've prepared and integrated a different, safer fix, affecting only Qt projects: http://hg.netbeans.org/cnd-main/rev/977a71acfbc4 Could you please test if it works for you? The deadline for patch 1 bugfixes has passed, but you can always use nightly builds from http://bits.netbeans.org/download/trunk/nightly/latest/
Alexey, Thanks! I will grab the nightly once it has been updated with your patch to test it (the latest nightly is from Jan 19th as of this comment). BTW: Since the deadline for NB6.8p1 has passed, when is patch 1 expected to be pushed out? I don't see any info posted on the Netbeans site (or is there a mailing list I should subscribe to so I can track such information?)
5 February
Integrated into 'main-golden', will be available in build *201001240200* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/977a71acfbc4 User: Alexey Vladykin <alexey_vladykin@netbeans.org> Log: #178039 Build fails on Mac OS X when linking to dylib/.a from Qt project
I hope silence means that the fix works :) So I'm closing this bug. Feel free to reopen if you find issues with the fix.
latest stable build is 201001190201. I don't think many people can check this fix.
I have been checking for a new nightly build several times per day... but the latest nightly build (Jan 19th) is before your patch so I have been unable to verify that the fix works. Cheers!
We have a less official place for development builds: http://bertram.netbeans.org/hudson/job/cnd-main/. You can try a build from there. Those builds do not include installer, so just unpack the zip archive and run netbeans/bin/netbeans.
I finally checked the latest nightly build with this fix (nightly-201003110200) and the problem is NOT fixed on Windows (same linker error as originally reported). On MacOS X, C++ applications will now link to dependent projects, but then CANNOT be run or debugged from Netbeans 6.8 due to the application being unable to find the .dylib(s) created by the dependent projects. This *used* to be fixable by using my toolchain .xml changes which added "-Wl,-rpath," to <dynamic_library_search>. However, my attached toolchain .xml fix appears to be ignored now, so I have to stick with Netbeans v6.8 release (pre-patches and have to ignore all updates) otherwise I can't use Netbeans for development. So from my perspective, this bug actually got worse after the patch, as I can no longer work around the problem. I plan on attaching a sample project in the next couple of days so this can (hopefully) be fixed by v6.9. Is there anything else I can provide to help? Thanks.
Yes, you can help by answering the questions below and by attaching sample projects. AFAIK, the -Wl,-rpath does not (and can not) work on Windows, because EXE file format does not support embedding library search paths. Are you sure putting -Wl,-rpath into toolchain .xml helped? Could you please double-check? A similar situation took place on MacOS until they added -rpath option to the linker in Xcode 3.0 (http://developer.apple.com/mac/library/releasenotes/DeveloperTools/RN-Id/index.html). In NetBeans we work this around by adding required dirs to PATH (on Windows) or DYLD_LIBRARY_PATH (on MacOS) when running or debugging the project. See o.n.m.cnd.makeproject.MakeActionProvider. Looks like you've found a case when the dirs are not added. So you could greatly help by providing two sample projects: one library and one application which depends on the library but fails to find it at runtime. P.S. -Wl,-rpath were removed from toolchain .xmls due to bug #153409.
Alexey, I am attaching 2 projects which are not working on MacOS X. Extract and try to build "NBQtApplication". I took another look at the Windows usage of "-Wl,-rpath" and you are correct, it is not allowing the application to run successfully... that is in a PATH environment variable which I missed. However, the application won't actually LINK unless that "-Wl,-rpath," (with a comma at the end) is used. Probably because the linker path is no longer "floating" and is explicitly used by "-Wl,-rpath," even if the EXE ignores it... I will check and follow up with my results with the latest nightly for Windows... On Mac OS X, attempting to build NBQtApplication with Netbeans Nightly 201003160201 fails with: /usr/bin/make -f nbproject/Makefile-Debug.mk QMAKE=/usr/bin/qmake SUBPROJECTS= .clean-conf /usr/bin/qmake VPATH=. -o qttmp-Debug.mk nbproject/qt-Debug.pro mv -f qttmp-Debug.mk nbproject/qt-Debug.mk mv: rename qttmp-Debug.mk to nbproject/qt-Debug.mk: No such file or directory make[1]: *** [nbproject/qt-Debug.mk] Error 1 make: *** [.clean-impl] Error 2 CLEAN FAILED (exit value 2, total time: 1s)
Created attachment 95349 [details] Nightly fails to clean on MacOS X.
Dustin, Clean failure on Mac is a regression introduced by an unrelated changeset http://hg.netbeans.org/cnd-main/rev/fa3cf1e92c51. I've just fixed it in http://hg.netbeans.org/cnd-main/rev/ac5fda6b89a2 After the fix I tried your projects again. I added to the NBQtApplication a dependency on NBLibrary (Linker->Libraries->Add Project...). Application compiled fine, and I could also execute it successfully. So I still can't reproduce your problem.
I'm closing this bug because the original problem with build failure is resolved. If there is another problem with running/debugging, please file a new bug. Thanks.
Alexey, I just tested this with Netbeans Nightly 201003240200 on Mac OS X and it now WORKS!! So it appears it got fixed at some point. Thank you for your help looking into this problem, I much appreciate it! Cheers!