Re: [Development] Qt 5.5.0 build issue on OS X (10.9): OpenGL libraries
On 9/11/2015 9:19 AM, René J.V. Bertin wrote: > On Friday September 11 2015 14:17:23 René J.V. Bertin wrote: > >> How can I find out why QMAKE_LIBS_OPENGL gets set to -lGL in qmodule.pri, or >> why the library is tested in opengldesktop.pro? > > Answer 1: by sinking teeth where I'd rather not sink them > Answer 2: configure shouldn't use pkg-config when building for the Cocoa QPA, > i.o.w, > > if [ "$QT_QPA_DEFAULT_PLATFORM" = "cocoa" ] || [ "$QT_QPA_DEFAULT_PLATFORM" = > "" -a "$XPLATFORM_MAC" = "yes" ] then compileTest should be used. I cannot > see any reason to justify using pkg-config to find the OpenGL frameworks, > just as it's obvious that it should be used to find the GLX library when > building the XCB plugin. > > Should I file a bug report or is this enough? This is the bug report I previously filed on this: https://bugreports.qt.io/browse/QTBUG-47146 It's definitely a problem caused by pkg-config if your pkg-config is set to search your X11 installation by default (using PKG_CONFIG_LIBDIR at least can override the default). A conditional that *doesn't* use pkg-config to find OpenGL on Cocoa would be very nice. Hanspeter ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] OS X plugin naming bug
On 11/18/2014 2:18 PM, Stephen Kelly wrote: Hanspeter Niederstrasser wrote: I have not been able to find the code that generates the .cmake files to figure out why it is not honoring the file extension change. Here they are: qtbase/mkspecs/features/create_cmake.prf qtbase/mkspecs/features/data/cmake/* Thanks. mkspecs/features/create_cmake.prf is exactly what I was looking for. Hanspeter ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] OS X plugin naming bug
On OS X, Qt is building plugins as dynamic libraries, instead of bundles, which is the more appropriate format for the platform. This was filed as QTBUG 2227 six years ago, but it was marked as closed without any work done on it, even though there was a patch listed. For the Fink package manager, we have been successful in locally patching the Qt4 and Qt5 sources to correct the plugin file type and extension. However, when I tried to start building the KDE5 frameworks on OS X, a new related issue appeared whereas the Qt5 cmake files referenced the plugin with the original .dylib extension and not the patched .so extension that the physical file is now using (this is all documented in QTBUG 2227). I have not been able to find the code that generates the .cmake files to figure out why it is not honoring the file extension change. It was suggested on IRC that I reach out to the qt-dev mailing list to get a fresh look at QTBUG 2227. Thank you for your help, Hanspeter ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] OS X plugin naming bug
On Fri, November 14, 2014 9:58 am, Thiago Macieira wrote: 2) User applications have plugins of their own I don't think this would impact an end user app with its own plugins that also uses Qt5 plugins. The application would have been compiled with the paths for dlopen to search for its own plugins. And the Qt5 libraries will be compiled with their own paths for dlopen to search in. Nothing has linked to the Qt plugins, so there's no issue when the Qt plugin file names change (as opposed to changing the install_name and filename for a dylib, which would be a problem) between Qt releases if this bug is fixed. Hanspeter -- ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] OS X plugin naming bug
On Fri, November 14, 2014 1:01 pm, Thiago Macieira wrote: On Friday 14 November 2014 12:43:40 Hanspeter Niederstrasser wrote: On Fri, November 14, 2014 9:58 am, Thiago Macieira wrote: 2) User applications have plugins of their own I don't think this would impact an end user app with its own plugins that also uses Qt5 plugins. The application would have been compiled with the paths for dlopen to search for its own plugins. And the Qt5 libraries will be compiled with their own paths for dlopen to search in. Nothing has linked to the Qt plugins, so there's no issue when the Qt plugin file names change (as opposed to changing the install_name and filename for a dylib, which would be a problem) between Qt releases if this bug is fixed. I don't understand your answer. You're saying that nothing has linked to the Qt plugins. Well, of course. By definition, a plugin is something you don't link to. Right. I guess I was just restating the obvious difference to dylibs, where file name (technically the install_name) continuity is important and is hardcoded into the application that links to that library. Yet that has nothing to do with either problem I listed. In specific for user plugins, if the file name were to change, the application code may fail to find it. I don't think this would happen. dlopen searches paths for a compatible file. It doesn't search for a specific file name. https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man3/dlopen.3.html Hanspeter -- More agile than a turtle, stronger than a mouse, nobler than a lettuce ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
