Re: [osg-users] OpenSceneGraph-3.6.5 release candidate 2 tagged, please test
Hi Robert, OSG 3.6.5-rc2 built fine on Windows with VC2019 (so VC2017 is probably OK) and appears to be running properly in our application. If there are more RCs I can try to test those and I should be able to get 3.6.5 binaries posted soon after it is released. Other than the usual mods I make to build with VC using GNU make the FBX plugin support has some issues that I worked around, wrt CMake usage and support for the newer VC and FBX versions. I can share my fixed versions if you would like and you tell me the best way to do that now. Cheers, Stuart -- You received this message because you are subscribed to the Google Groups "OpenSceneGraph Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to osg-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/osg-users/19f2d491-8ffc-45fc-b7fe-5126c48ea797%40googlegroups.com. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [ANN] OSG 3.6.4 Windows VC++ Binaries Posted
Hello dear OSG-community, The OSG 3.6.4 Windows binaries at https://objexx.com/OpenSceneGraph.html were refreshed with the latest 3rd party packages and the just-released Qt 5.13.2. This refresh adds support for both the old osgQt (that is now in their Qt4 branch) and the new osgQOpenGL approach (from the current osgQt git master branch). This should let projects transition to osQOpenGL when they are ready (and can get it to work in their applications, which we haven't managed yet!). Best regards, Stuart -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=76865#76865 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [ANN] OSG 3.6.4 Windows VC++ Binaries Posted
Hello OSG-community, OSG 3.6.4 Windows 64-bit binaries built with Visual C++ 2017 are now available from this page on my company's site: https://objexx.com/OpenSceneGraph.html Release and debug builds are provided. Plugins for curl, FBX, freetype, GDAL, giflib, glut, jpeg, lpng, minizip, tiff, and zlib are included. The FBX plugin is a new addition based on a recent request. osgQt is included but from the April 2018 Qt4-tagged revision: we haven't figured out how to migrate to the new osgQOpenGL system yet! Other builds and additional plugins may be possible by arrangement. [Robert, feel free to a another link to the Stable release 3.6.4 entry as you did for 3.6.3.] Best regards, Stuart -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=76645#76645 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osg::Cylinder height change not shown in OSG 3.6.3
Hi, I have an osg::Cylinder in an osg::ShapeDrawable and I change its height in an UpdateCallback like this: Code: cylinder->setHeight( h ); drawable->dirtyDisplayList(); drawable->dirtyBound(); This works in OSG 3.4.1 but with OSG 3.6.3 (at least on my Windows builds) the height change doesn't show up. Checking the value with getHeight shows that the cylinder height is updated so maybe the issue is that dirtyDisplayList is no longer sufficient to trigger the display update. I can try to put together a small self-contained example if this doesn't give anyone a clue what is going on. Any help will be much appreciated. And if this has exposed an OSG bug it would be good to fix for 3.6.4. Thanks! Cheers, Stuart -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=75246#75246 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [ANN] OSG 3.6.3 Windows VC++ Binaries Posted
Hi Robert, robertosfield wrote: > > That's a great contribution. Are you OK will me adding a link to the > Downloads page pointing at these binaries? > Yes, that would make it easier for people to find them. Cheers, Stuart -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=75155#75155 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [ANN] OSG 3.6.3 Windows VC++ Binaries Posted
Hello dear OSG-community, OSG 3.6.3 Windows binaries built with Visual C++ 2017 are now available from this page on my company's site: http://objexx.com/OpenSceneGraph.html Release and debug builds are provided. osgQt built from the git master head is included. The curl, freetype, GDAL, giflib, glut, jpeg, lpng, minizip, tiff, and zlib plugins are included and the versions are shown on the page. The GDAL plugin is new in the OSG 3.6.3 builds. A ReadMe.txt file in the root directory of the expanded package has some details. These are 64-bit builds with the default GL2 OpenGL level. Other builds and additional plugins may be provided upon request. Best regards, Stuart -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=75150#75150 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgQt + OSG 3.6.2 Status
Circling back to my original issue, I got my OSG Qt viewer widget running with OSG 3.6.2 and osgQt by moving all the GL-related boilerplate after the main window show() call happens. I'm not sure what changed in Qt or osgQt to require this but this could be useful for other osgQt users. Wojtek: thanks. I was already doing camera->setDrawBuffer(GL_BACK) but that does seem to be another thing that we didn't used to need. Maybe the osgQt docs should collect these migration tips. A minor annoyance remains that I didn't have before: the OSG viewer is in a tab widget and I have to setCurrentWidget to a different tab and then back on to the OSG widget tab to get the OSG model to appear. No explicit repaint, updateGL, etc. calls worked. On a related note, I got a tip to use Code: QApplication::setAttribute(Qt::AA_DontCheckOpenGLContextThreadAffinity, true); to allow use of multithreading in Qt 5. It does allow things to run but I'm not sure if this is safe. Thoughts? As far as the lively Qt discussion, I think you are all correct. Qt is probably the best cross-platform GUI framework we have AND it is deeply flawed. QML is nifty for mobile/etc GUIs but it is causing the C++ side to be neglected. Qt3D is getting pretty good but may not be up to serious visualization applications out of the box yet. E.g., I'll have to write a manipulator to get close to OSG's great trackball. Our application is well-layered so that we can easily keep experimenting in a Qt3D branch while using OSG for production builds. I hope that osgQt will keep up with Qt and that solutions for the integration and multithreading can be found. Maybe we can get more involvement from the Qt devs -- they are certainly aware and supportive of the OSG integration. Cheers, Stuart -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=74418#74418 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgQt + OSG 3.6.2 Status
Hi Andrew, I had no luck despite trying many variations. I had to put this work aside for a while with the plan to circle back and check for osgQt updates now and then. But if someone adds some ideas here I'll try them. To be honest I'm experimenting with Qt3D (feels a little dirty ;-). I know I won't get OSG performance out of it but the reduced Qt integration, Qt5, multithreading, and packaging hassles might make this a viable alternative soon. Qt3D has its own headaches, of course, and is still fairly immature. Maybe I can join a support group for OSG users with a wandering eye. Cheers, Stuart -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=74396#74396 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgQt + OSG 3.6.2 Status
Thanks for the outline. I will work through this and experiment with my code. If I learn anything interesting/useful I'll post it. Cheers, Stuart -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=74360#74360 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgQt + OSG 3.6.2 Status
Hi Robert, Yes, I'm aware of the examples and osgQtWidgets runs fine with my builds. But none of them match how we have used osgQt in the past with a single-view class derived from osgQt::GLWidget and osgViewer and a GraphicsWindowQt. And there are no examples for the new osgQOpenGL approach. My viewer code works fine in OSG 3.4.1 on Windows and Linux but doesn't work with 3.6.2 and the current osgQt master, and I'm not sure where the problem lies. Cheers, Stuart -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=74358#74358 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgQt + OSG 3.6.2 Status
Thanks for the info @davisjamesf. I wish I knew what secret sauce was needed to get this running. I'll keep trying and maybe I'll have luck with some future osgQt release. If you or anyone have some example code for a single view class derived from osgQt::GLWidget and osgViewer (or a better design) that can display a scene using current osgQt + OSG 3.6.2 that should get me started. Thanks, Stuart -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=74354#74354 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgQt + OSG 3.6.2 Status
Hi, I'm looking for info on the status of osgQt for OSG 3.6.2. I tried using the osgQt git master code with my OSG 3.6.2 + Qt 5.11.1 Windows build but I get a black OSG widget with our application, which works fine with OSG 3.4.1. I tried a number of variations with no luck. I also tried the new osgQOpenGL code but without examples I couldn't get it working correctly. If either of these osgQt approaches are working with OSG 3.6.2 for anyone else it would be helpful to get any usage tips. Once we have a compatible osgQt we plan to post the OSG 3.6.2 + osgQt Windows binaries to our company site like we do for 3.4.0 and 3.4.1. Thanks, Stuart -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=74345#74345 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Where can i find the windows binaries
Hi Peter, My company, Objexx (http://objexx.com), is providing Windows binaries at this page: http://objexx.com/OpenSceneGraph.html. We have 3.4.0 and 3.4.1 and we'll be doing 3.6.1 with Qt 5.11 soon. If you have special requirements or you need 3.6.1 ASAP let me know. Cheers, Stuart -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=73905#73905 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [EXTERNAL] Re: Is there a binary distribution available for version 3.4.0?
Hi Brian, No, we aren't using VS 2013 any more. If you are in a pickle for VS 2013 builds contact me and we'll look at the options for getting that done. Regards, Stuart -- Stuart Mentzer Objexx Engineering /Office/ +1 781 455 1150 x11 /Mobile/ +1 781 708 3872 On 10/5/2017 1:59 PM, Brian Davis wrote: Thanks for the response, Stuart. Much appreciated. Do you have a Visual Studio 2013 version? It looks like no, based on your web site, but I wanted to ask. Cheers, Brian *From:*osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] *On Behalf Of *Stuart Mentzer *Sent:* Thursday, October 05, 2017 2:26 AM *To:* osg-users@lists.openscenegraph.org *Subject:* [EXTERNAL] Re: [osg-users] Is there a binary distribution available for version 3.4.0? *External Sender: Use caution with links/attachments.** * Hi Brian, I'm not sure what your definition of publicly maintained is but my company is providing Windows builds of OSG 3.4.0 at http://objexx.com/OpenSceneGraph.html <https://urldefense.proofpoint.com/v2/url?u=http-3A__objexx.com_OpenSceneGraph.html&d=DwMDaQ&c=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=5bxVULx1mckzDfACIFrAQIBf0kuZWt0S6r7kBSswDmQ&m=LhI3dmNBsTDv9bkGafOzomUka-OKRj3XlwK8-R1kvIc&s=dvVyThGuzcsE-4xj1nxcPYAyEfWm1MyfhgHGuojwh5w&e=>. We set up an automated build system because we need these binaries ourselves and we found no other source for recent releases. We are willing to entertain requests for additional 3rd party libraries and for builds of development releases. We will be posting 3.4.1 binaries within the next couple of weeks (waiting for Qt 5.9.2 or 5.10) and we could also post 3.4.0 builds with up-to-date 3rd party library versions. If you have any questions about our builds just let me know. Regards, Stuart -- Stuart Mentzer Objexx Engineering On 10/5/2017 3:01 AM, Brian Davis wrote: Are there any publicly maintained binary distributions of version 3.4.0 available for Windows? For purposes of IP compliance scans of our software, use of a publicly maintained binary distribution works better than building it ourselves. We currently have binaries that we have built, but are interested in using a public binary distribution if available. Thanks, Brian -- This e-mail, including any attached files, may contain confidential and privileged information for the sole use of the intended recipient. Any review, use, distribution, or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive information for the intended recipient), please contact the sender by reply e-mail and delete all copies of this message. ___ osg-users mailing list osg-users@lists.openscenegraph.org <mailto:osg-users@lists.openscenegraph.org> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openscenegraph.org_listinfo.cgi_osg-2Dusers-2Dopenscenegraph.org&d=DwMDaQ&c=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=5bxVULx1mckzDfACIFrAQIBf0kuZWt0S6r7kBSswDmQ&m=LhI3dmNBsTDv9bkGafOzomUka-OKRj3XlwK8-R1kvIc&s=J3kb84kmZN6_y9WNFSFwGpYfyMqEV9nnn0zSNiDckQI&e=> ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Is there a binary distribution available for version 3.4.0?
Hi Brian, I'm not sure what your definition of publicly maintained is but my company is providing Windows builds of OSG 3.4.0 at http://objexx.com/OpenSceneGraph.html. We set up an automated build system because we need these binaries ourselves and we found no other source for recent releases. We are willing to entertain requests for additional 3rd party libraries and for builds of development releases. We will be posting 3.4.1 binaries within the next couple of weeks (waiting for Qt 5.9.2 or 5.10) and we could also post 3.4.0 builds with up-to-date 3rd party library versions. If you have any questions about our builds just let me know. Regards, Stuart -- Stuart Mentzer Objexx Engineering // On 10/5/2017 3:01 AM, Brian Davis wrote: Are there any publicly maintained binary distributions of version 3.4.0 available for Windows? For purposes of IP compliance scans of our software, use of a publicly maintained binary distribution works better than building it ourselves. We currently have binaries that we have built, but are interested in using a public binary distribution if available. Thanks, Brian -- This e-mail, including any attached files, may contain confidential and privileged information for the sole use of the intended recipient. Any review, use, distribution, or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive information for the intended recipient), please contact the sender by reply e-mail and delete all copies of this message. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Call for testing, preparing for 3.5.6 dev release again :-)
Hi Robert (and Mourad), I tried -T v140 but I still didn't seem to get that variable set, with or without the -G option. And note that I use MinGW makefiles even when building with MSVC so deducing partially from -G won't work right in that case anyway. From this page (https://cmake.org/cmake/help/latest/variable/CMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION.html) it looks like Windows 10 may do things a little differently (I'm on Win10). I guess the discussion from http://forum.openscenegraph.org/viewtopic.php?t=16592 may not be fully resolved yet. Cheers, Stuart -- Stuart Mentzer Objexx Engineering /Office/ +1 781 455 1150 x11 /Mobile/ +1 781 708 3872 On 5/15/2017 7:58 AM, Mourad Boufarguine wrote: Hi Robert, CMAKE_VS_PLATFORM_TOOLSET is not set unless the user explicitely specifies a toolset when invoking cmake : cmake -G "Visual Studio XX" -T v1YY srcDir If the user does not specify a toolset, the default toolset of the chosen Visual Studio version will be used, but the CMAKE_VS_PLATFORM_TOOLSET variable will not be set, and this is what is causing the problem here. Cheers, Mourad On Mon, May 15, 2017 at 1:23 PM, Robert Osfield mailto:robert.osfi...@gmail.com>> wrote: Hi Stuart, On 15 May 2017 at 12:07, Stuart Mentzer mailto:stuart_ment...@objexx.com>> wrote: > https://cmake.org/cmake/help/v3.0/variable/CMAKE_VS_PLATFORM_TOOLSET.html <https://cmake.org/cmake/help/v3.0/variable/CMAKE_VS_PLATFORM_TOOLSET.html> > > Which mentons that it's set for VC10 and above. Torben uses the > CMAKE_VS_PLATFORM_TOOLSET for vc8 and vc9 above, so I'm not what would > happen here. > > What VC number is reported on your system? > > Visual C++ 2015 corresponds to MSVC14. Looking at the CMake docs it would seem CMAKE_VS_PLATFORM_TOOLSET should be defined, but given your error it would seem on your system it's not. Could you check whether CMAKE_VS_PLATFORM_TOOLSET is defined and what it's value is? > [Separate issue: curl 7.54.0 (latest) has a build error under VC++ 2015 but > the prev version builds OK] > > Is this a build error in curl, or the OSG plugin building against curl > 7.54.0? > > It is in the curl build itself. Here is the bug report I filed: > https://github.com/curl/curl/issues/1482 <https://github.com/curl/curl/issues/1482> OK, this isn't an OSG issue then so I can safely leave this to someone else to resolve:-) Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org <mailto:osg-users@lists.openscenegraph.org> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org <http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org> ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Call for testing, preparing for 3.5.6 dev release again :-)
Hi Robert, On 5/15/2017 5:13 AM, Robert Osfield wrote: Hi Stuart, On 12 May 2017 at 14:32, Stuart Mentzer wrote: I always build from scratch in an empty build directory. Thanks for the clarification. Adding " around the 3rd and 4th args in the REPLACE lines did indeed eliminate the error. Torben should check that this is still OK when the Collada plugin is in use. I'm currently looking at the changes and the error report, trying to make sense of what is the root of the issue and how to resolve it. Unfortunately I haven't heard from Torben yet so don't yet know what his thoughts are. Form what I understand Torben introduced the COLLADA_BOOST_BUILDNAME to cope with variations under Windows related to the platform tools set, hence the introduction of the CMAKE_VS_PLATFORM_TOOLSET in the lines like: ELSEIF(MSVC14) SET(COLLADA_BUILDNAME "vc14") string(REPLACE "v" "vc" COLLADA_BOOST_BUILDNAME ${CMAKE_VS_PLATFORM_TOOLSET}) ELSEIF(MSVC12) SET(COLLADA_BUILDNAME "vc12") string(REPLACE "v" "vc" COLLADA_BOOST_BUILDNAME ${CMAKE_VS_PLATFORM_TOOLSET}) ELSEIF(MSVC11) SET(COLLADA_BUILDNAME "vc11") string(REPLACE "v" "vc" COLLADA_BOOST_BUILDNAME ${CMAKE_VS_PLATFORM_TOOLSET}) ELSEIF(MSVC10) SET(COLLADA_BUILDNAME "vc10") string(REPLACE "v" "vc" COLLADA_BOOST_BUILDNAME ${CMAKE_VS_PLATFORM_TOOLSET}) ELSEIF(MSVC90) SET(COLLADA_BUILDNAME "vc9") string(REPLACE "v" "vc" COLLADA_BOOST_BUILDNAME ${CMAKE_VS_PLATFORM_TOOLSET}) ELSEIF(MSVC80) SET(COLLADA_BUILDNAME "vc8") string(REPLACE "v" "vc" COLLADA_BOOST_BUILDNAME ${CMAKE_VS_PLATFORM_TOOLSET}) ELSE(APPLE) CMaker docs for the CMAKE_VS_PLATFORM_TOOLSET} are: https://cmake.org/cmake/help/v3.0/variable/CMAKE_VS_PLATFORM_TOOLSET.html Which mentons that it's set for VC10 and above. Torben uses the CMAKE_VS_PLATFORM_TOOLSET for vc8 and vc9 above, so I'm not what would happen here. What VC number is reported on your system? Visual C++ 2015 corresponds to MSVC14. [Separate issue: curl 7.54.0 (latest) has a build error under VC++ 2015 but the prev version builds OK] Is this a build error in curl, or the OSG plugin building against curl 7.54.0? It is in the curl build itself. Here is the bug report I filed: https://github.com/curl/curl/issues/1482 Thanks, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org Cheers, Stuart ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Call for testing, preparing for 3.5.6 dev release again :-)
I always build from scratch in an empty build directory. What platform and build tools are you using? The use of REPLACE was introduced in a submission from Torben related to VS2017 binary support: https://github.com/openscenegraph/OpenSceneGraph/commit/67ef816da00441121f7b2cb606ee19bbb1f15e80 We could revert this but it'd break support for VS2017 binaries... I don't have any suggestions yet on what an appropriate fix might be. I'm not a Windows dev so will need to defer resolution to those with WIndows expertise. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org Hi Robert, Adding " around the 3rd and 4th args in the REPLACE lines did indeed eliminate the error. Torben should check that this is still OK when the Collada plugin is in use. [Separate issue: curl 7.54.0 (latest) has a build error under VC++ 2015 but the prev version builds OK] Cheers, Stuart ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Call for testing, preparing for 3.5.6 dev release again :-)
I always build from scratch in an empty build directory. What platform and build tools are you using? The use of REPLACE was introduced in a submission from Torben related to VS2017 binary support: https://github.com/openscenegraph/OpenSceneGraph/commit/67ef816da00441121f7b2cb606ee19bbb1f15e80 We could revert this but it'd break support for VS2017 binaries... I don't have any suggestions yet on what an appropriate fix might be. I'm not a Windows dev so will need to defer resolution to those with WIndows expertise. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org Windows 10 (64-bit), CMake 3.8.1, Visual C++ 2015. My guess is that it just needs a fixup to deal with the case of NOT building the Collada plugin, when those strings are probably empty. I'll kick off a build with the quote-wrapping fix and let you know later but it is probably best to ask Torben to take a look. Cheers, Stuart ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Call for testing, preparing for 3.5.6 dev release again :-)
On 5/12/2017 4:50 AM, Robert Osfield wrote: Hi Stuart, On 12 May 2017 at 09:18, Stuart Mentzer wrote: I don't think it is a change in CMake: it looks like REPLACE has had the same syntax since at least 3.0: string(REPLACE [...]) The version of FindCOLLADA.cmake in 3.4.0 didn't have the REPLACE lines, so I guess that is where the problem lies. The (first) offending line is: string(REPLACE "v" "vc" COLLADA_BOOST_BUILDNAME ${CMAKE_VS_PLATFORM_TOOLSET}) Since I am not building with the Collada plugin I assume one or both of the last 2 arguments are blank, thus too few args. Probably wrapping them in " would fix it but I haven't had a chance to try that yet. Maybe best to kick this to the contributor of the revised FindCOLLADA.cmake. Do you clean your CMakeCache.txt and run CMake from scratch when you did your testing? I am wondering if an new CMake variable is intended to be set elsewhere in the OSG that isn't being set it your case. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org Hi Robert, I always build from scratch in an empty build directory. Cheers, Stuart ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Call for testing, preparing for 3.5.6 dev release again :-)
I don't think it is a change in CMake: it looks like REPLACE has had the same syntax since at least 3.0: string(REPLACE [...]) The version of FindCOLLADA.cmake in 3.4.0 didn't have the REPLACE lines, so I guess that is where the problem lies. The (first) offending line is: string(REPLACE "v" "vc" COLLADA_BOOST_BUILDNAME ${CMAKE_VS_PLATFORM_TOOLSET}) Since I am not building with the Collada plugin I assume one or both of the last 2 arguments are blank, thus too few args. Probably wrapping them in " would fix it but I haven't had a chance to try that yet. Maybe best to kick this to the contributor of the revised FindCOLLADA.cmake. Cheers, Stuart On 5/12/2017 3:56 AM, Robert Osfield wrote: HI Stuart, On 12 May 2017 at 02:04, Stuart Mentzer wrote: Current master build fails on Windows with: CMake Error at CMakeModules/FindCOLLADA.cmake:37 (string): string sub-command REPLACE requires at least four arguments. Call Stack (most recent call first): CMakeLists.txt:743 (FIND_PACKAGE) Details: Windows 10, CMake 3.8.1, Visual C++ 2015 Is this error due to recent changes in the OSG or an issue introduced by CMake 3.8.1? Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Call for testing, preparing for 3.5.6 dev release again :-)
Hi Robert, Current master build fails on Windows with: CMake Error at CMakeModules/FindCOLLADA.cmake:37 (string): string sub-command REPLACE requires at least four arguments. Call Stack (most recent call first): CMakeLists.txt:743 (FIND_PACKAGE) Details: Windows 10, CMake 3.8.1, Visual C++ 2015 Cheers, Stuart -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=70901#70901 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test OpenSceneGraph master in prep for 3.5.6 dev release
Hi Robert, robertosfield wrote: > Hi Stuart, > > On 28 March 2017 at 19:46, Stuart Mentzer <> wrote: > > > osgWrappers/serializers/osgVolume/MultipassTechnique.cpp was added since my > > prior (successful) build with VC++ 2015 (at rev 6308b4). VC++ needs the > > definition of osg::Texture2D (and other types used in members) to > > instantiate MultipassTechnique. > > > > That is a really useful clue. My best guess is that we need to add an > #include to the MultipassTechnique header. > > I have checked this change into OSG master. Could you test it and let > me know if it resolves the build errors? > > Thanks, > Robert. The VC++ 2015 build now completes without error and seems fine with my application. Cheers, Stuart -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=70602#70602 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test OpenSceneGraph master in prep for 3.5.6 dev release
robertosfield wrote: > Hi Stuart, > > I don't recall resent changes to the files mentioned in your compiler > output, this makes a bit more difficult to point point what might have > caused this problem. > > When was the last time you build OSG master? Was it with the same > OS/Compiler set? Did you come across problems then? > > Robert. Hi Robert, osgWrappers/serializers/osgVolume/MultipassTechnique.cpp was added since my prior (successful) build with VC++ 2015 (at rev 6308b4). VC++ needs the definition of osg::Texture2D (and other types used in members) to instantiate MultipassTechnique. Cheers, Stuart -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=70591#70591 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test OpenSceneGraph master in prep for 3.5.6 dev release
Hi Robert, Getting an error with a VC++ 2015 64-bit build on Windows 10: cd /d C:\Projects\OSG\OpenSceneGraph.VC.r\OSG\src\osgWrappers\serializers\osgVolume && C:\PROGRA~2\MICROS~1.0\VC\bin\amd64\cl.exe/TP -D_CRT_SECURE_NO_DEPRECATE -D_SCL_SECURE_NO_WARNINGS -Dosgdb_serializers_osgvolume_EXPORTS -IC:\Projects\OSG\OpenSceneGraph\include -IC:\Projects\OSG\OpenSceneGraph.VC.r\OSG\include /DWIN32 /D_WINDOWS /W3 /GR /EHsc /W4 /wd4589 /wd4706 /wd4127 /wd4100 /Zp16 /nologo /EHsc /DNOMINMAX /DNDEBUG /O2 /GS- /MD /FoCMakeFiles\osgdb_serializers_osgvolume.dir\MultipassTechnique.cpp.obj /FdCMakeFiles\osgdb_serializers_osgvolume.dir/ /FS -c C:\Projects\OSG\OpenSceneGraph\src\osgWrappers\serializers\osgVolume\MultipassTechnique.cpp C:\Projects\OSG\OpenSceneGraph\include\osg/ref_ptr(41): error C2027: use of undefined type 'osg::Texture2D' C:\Projects\OSG\OpenSceneGraph\include\osg/FrameBufferObject(264): note: see declaration of 'osg::Texture2D' C:\Projects\OSG\OpenSceneGraph\include\osg/ref_ptr(41): note: while compiling class template member function 'osg::ref_ptr::~ref_ptr(void)' C:\Projects\OSG\OpenSceneGraph\include\osgVolume/MultipassTechnique(116): note: see reference to function template instantiation 'osg::ref_ptr::~ref_ptr(void)' being compiled C:\Projects\OSG\OpenSceneGraph\include\osgVolume/MultipassTechnique(70): note: see reference to class template instantiation 'osg::ref_ptr' being compiled C:\Projects\OSG\OpenSceneGraph\include\osg/ref_ptr(41): error C2227: left of '->unref' must point to class/struct/union/generic type src\osgWrappers\serializers\osgVolume\CMakeFiles\osgdb_serializers_osgvolume.dir\build.make:352: recipe for target 'src/osgWrappers/serializers/osgVolume/CMakeFiles/osgdb_serializers_osgvolume.dir/MultipassTechnique.cpp.obj' failed make[2]: *** [src/osgWrappers/serializers/osgVolume/CMakeFiles/osgdb_serializers_osgvolume.dir/MultipassTechnique.cpp.obj] Error 2 I didn't have a chance to look into the code to debug it but looks like maybe a missing include. Cheers, Stuart[/code] -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=70576#70576 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test OpenSceneGraph master in prep for 3.5.6 dev release
Hi Robert, robertosfield wrote: > HI Stuart, > > On 27 March 2017 at 13:44, Stuart Mentzer <> wrote: > > > With this fix OSG + osgQt master branches build and work fine for my > > application on Windows 10 with Visual C++ 2015 and Qt 5.8.0. > > > > I haven't done any testing under Windows so can't comment on whether > OSG master will building under Qt5.8.0+VS20015, I do these calls for > testing to get feedback from the community on things like this - there > is one of me and many different platforms so I have to rely on the > community to cover the wide range of build combinations. > > If there are reports of issues then I can help work to resolve them. Just to clarify, since maybe you misread my comment as a question, I did the Qt 5.8.0+VS2015 build with today's masters and I am reporting that all seems well. robertosfield wrote: > > > > I also built OSG with Visual C++ 2017 for kicks and it seemed to build > > cleanly but I didn't test it with my application because I need osgQt and > > that won't build with VC++ 2017 until Qt 5.9.0 comes out. > > > > Was it a recent OSG master that you tested? I did this VC++ 2017 build with master as of 2 days ago. Cheers, Stuart -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=70566#70566 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test OpenSceneGraph master in prep for 3.5.6 dev release
Hi Robert, With this fix OSG + osgQt master branches build and work fine for my application on Windows 10 with Visual C++ 2015 and Qt 5.8.0. I also built OSG with Visual C++ 2017 for kicks and it seemed to build cleanly but I didn't test it with my application because I need osgQt and that won't build with VC++ 2017 until Qt 5.9.0 comes out. I did no code migrations for 3.5.6 but if there are any notes on suggested migration that it would be great to get a link. I believe new approaches to Qt5 integration are being worked on but I didn't look into that either. Cheers, Stuart -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=70557#70557 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Linux packaging: Qt 4 vs 5
The Fedora OSG packager added this comment to the Bugzilla entry: > Having experimented a bit with Qt4/Qt5 builts, I found this won't be easily > achievable. > > - OSG-3.4.0's qt-libs/plugins/binaries use non-qt-versioned file > names/SONAMEs. I.e. qt4 and qt5-compiled binaries will conflict at > runtime/installation time. > > - Qt5-built OSG is slightly incompatible with Qt4-build versions of OSG-3.4.0. > (Building against QT5 causes OSG to drop the osgdb_qfont.so plugin) > > - OSG-3.4.0 monolytical [monolithic?] build system treats QT4 and QT5 as > mutually exclusive alternatives. > > All in all, I don't see an easy way to implement parallel installation of > qt4-/qt5-build variants. If these issues can't be finessed, separating just osgQt into Qt 4 and 5 packages won't suffice: we'll need separate OSG builds, installation paths, and library naming. But maybe someone more familiar with Linux builds can see a simpler approach. Having both Qt 4 and 5 builds on Linux seems to have value but if that's not practical it might be time with OSG 3.6.0 to encourage Linux packagers to switch to Qt 5. Stuart[/quote] -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=68162#68162 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Linux packaging: Qt 4 vs 5
On Fri, Jul 15, 2016 at 9:15 AM, Alberto Luaces wrote: I am able to run our OSG applications with Qt 5 on Windows and I'd like to try it on Linux to see if we can transition off Qt 4. Would it make sense to request OpenSceneGraph-qt5 packages be added by the main distros? (I am assuming those are the only OSG packages with Qt dependencies.) If so, how best to do that? Personally I think that it would make sense. You would usually file a bug report against the OSG package. For example, Debian has a "wish-list" category for that kind of petitions. You could also address the maintainer personally. The Fedora procedure would be to file a bug at https://bugzilla.redhat.com. You can try to email openscenegraph-ow...@fedoraproject.org afterwards. Done for Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=1357109 From https://packages.debian.org/experimental/openscenegraph-3.4 and https://www.archlinux.org/packages/community/x86_64/openscenegraph/ it looks like 3.4.0 is built against Qt5 in Debian and Arch, excluding building applications with Qt4, which isn't desirable either. Having distinct osgQt 4 and 5 packages as Robert describes seems like the best way to encourage packagers to provide them both (even if most of the differences are in the examples). François ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org Stuart ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Linux packaging: Qt 4 vs 5
Hello, The OpenSceneGraph-qt/-devel (OSG 3.4.0) packages on Fedora 24 are built against Qt 4. I'm wondering if that is suggested by OSG (maybe due to the single thread restriction on Qt 5) or is the choice of the Fedora packager. I am able to run our OSG applications with Qt 5 on Windows and I'd like to try it on Linux to see if we can transition off Qt 4. Would it make sense to request OpenSceneGraph-qt5 packages be added by the main distros? (I am assuming those are the only OSG packages with Qt dependencies.) If so, how best to do that? Thanks, Stuart ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Virtual base initialization issues
Hi Robert, That is surprising and unfortunate -- in this instance VC++ is actually correct. If you know which compilers gave contradictory warnings I might be able to see if that has now been corrected. In any event, it seems better to have correct code give erroneous warnings than incorrect code that gives correct warnings. I think there 2+ classes which aren't properly initializing the virtual bases, at least on compilers that handle virtual bases correctly. So there may be actual bugs, not just warnings. I am willing to pursue this if you would like me to. Stuart -- Stuart G Mentzer Objexx Engineering Office 1.781.455.1150 x11 Mobile 1.781.708.3872 On 6/30/2016 4:29 AM, Robert Osfield wrote: Hi Stuart, This warning is a bit of pain. Fix this warning and you generate a warning with other compilers depending upon which compiler and warning options enabled. We had a discussion and attempted to fix some of these warnings in the last dev release cycle. Robert. On 30 June 2016 at 06:08, Stuart Mentzer wrote: Hello, Visual C++ 2015 finds a problem (in current master) with the initialization of virtual base classes in the constructors of the hierarchies including Object, Callback, NodeCallback, GUIEventHandler, EventHandler, CameraManipulator, StandardManipulator, and AnimationManagerBase. Constructors are attempting to initialize virtual bases Object and Callback from classes that are not the most-derived, concrete class so those initializations are being ignored. It doesn't help (or look right) that multiple levels in the hierarchy attempt (and fail) to initialize these virtual bases. An example of the reported warnings is: C:\Projects\OSG\OpenSceneGraph\src\osgGA\CameraManipulator.cpp(24): warning C4589: Constructor of abstract class 'osgGA::CameraManipulator' ignores initializer for virtual base class 'osg::Object' C:\Projects\OSG\OpenSceneGraph\src\osgGA\CameraManipulator.cpp(24): note: virtual base classes are only initialized by the most-derived type C:\Projects\OSG\OpenSceneGraph\src\osgGA\CameraManipulator.cpp(25): warning C4589: Constructor of abstract class 'osgGA::CameraManipulator' ignores initializer for virtual base class 'osg::Callback' C:\Projects\OSG\OpenSceneGraph\src\osgGA\CameraManipulator.cpp(25): note: virtual base classes are only initialized by the most-derived type In some cases I see the most-derived classes also do the (correct) virtual base initialization but it looks like at least these 2 are missing it: BasicAnimationManager::BasicAnimationManager(const AnimationManagerBase& b, const osg::CopyOp& copyop) TimelineAnimationManager::TimelineAnimationManager(const TimelineAnimationManager& nc,const osg::CopyOp& co) I don't know enough of the internals to say if this could be causing problems in practice but it would be good to fix this usage. I'm willing to take a shot at it if that would be helpful. Stuart ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Virtual base initialization issues
Hello, Visual C++ 2015 finds a problem (in current master) with the initialization of virtual base classes in the constructors of the hierarchies including Object, Callback, NodeCallback, GUIEventHandler, EventHandler, CameraManipulator, StandardManipulator, and AnimationManagerBase. Constructors are attempting to initialize virtual bases Object and Callback from classes that are not the most-derived, concrete class so those initializations are being ignored. It doesn't help (or look right) that multiple levels in the hierarchy attempt (and fail) to initialize these virtual bases. An example of the reported warnings is: C:\Projects\OSG\OpenSceneGraph\src\osgGA\CameraManipulator.cpp(24): warning C4589: Constructor of abstract class 'osgGA::CameraManipulator' ignores initializer for virtual base class 'osg::Object' C:\Projects\OSG\OpenSceneGraph\src\osgGA\CameraManipulator.cpp(24): note: virtual base classes are only initialized by the most-derived type C:\Projects\OSG\OpenSceneGraph\src\osgGA\CameraManipulator.cpp(25): warning C4589: Constructor of abstract class 'osgGA::CameraManipulator' ignores initializer for virtual base class 'osg::Callback' C:\Projects\OSG\OpenSceneGraph\src\osgGA\CameraManipulator.cpp(25): note: virtual base classes are only initialized by the most-derived type In some cases I see the most-derived classes also do the (correct) virtual base initialization but it looks like at least these 2 are missing it: BasicAnimationManager::BasicAnimationManager(const AnimationManagerBase& b, const osg::CopyOp& copyop) TimelineAnimationManager::TimelineAnimationManager(const TimelineAnimationManager& nc,const osg::CopyOp& co) I don't know enough of the internals to say if this could be causing problems in practice but it would be good to fix this usage. I'm willing to take a shot at it if that would be helpful. Stuart ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] freetype build support on Windows
Hi Robert, Here is what should be the final version of FindFreetype.cmake that is based on the now-accepted CMake patches. This supports the new freetype include path structure and fixes the failure to find the debug library on Windows due to its name having a 'd' suffix. The only differences are wrt the license requirement when not bundled with CMake and the adjustments necessary to include CMake modules. Once the patches are part of OSG's oldest supported CMake this FindFreetype.cmake can be dropped from OSG. If you'd like me to post this to osg-submission just let me know. Cheers, Stuart -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=67722#67722 Attachments: http://forum.openscenegraph.org//files/findfreetype_213.7z ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] freetype build support on Windows
On 6/9/2016 9:15 AM, Robert Osfield wrote: Hi Stuart, On 9 June 2016 at 12:39, Stuart Mentzer wrote: Robert, it occurs to me that you could just do a find_library for PNG and then, if found, add the PNG lib to the freetype plugin libraries, even if freetype didn't actually depend on PNG. Maybe that isn't super rigorous but linking in a library that isn't needed should be harmless. This simpler task I can do for the freetype plugin CMakeLists.txt file if you want. I don't feel this is appropriate. If someone cherry picked plugins for release then could end up with problems if they didn't copy across png as well even though it shouldn't be needed. With CMake you can run build tests to test if certain capabilities work or not and then toggle settings accordingly, perhaps this might be useful on the FreeType front. If not then have a CMake option for the FreeType where you can add additional libraries or toggle on the requirement for linking to PNG. The later is the route I'd suggest for now. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org Good points, Robert. I'm not the one to do this fancier CMake setup. Stuart ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] freetype build support on Windows
Robert, it occurs to me that you could just do a find_library for PNG and then, if found, add the PNG lib to the freetype plugin libraries, even if freetype didn't actually depend on PNG. Maybe that isn't super rigorous but linking in a library that isn't needed should be harmless. This simpler task I can do for the freetype plugin CMakeLists.txt file if you want. Stuart On 6/8/2016 1:42 AM, Stuart Mentzer wrote: Hi Robert, If we do this in FindFreetype.cmake it will prevent us from using CMake's version (once the patch goes in). So that means doing it in the CMakeLists.txt for the freetype plugin. Anyway, I don't know enough CMake to find another package's dependencies (something with pkg_config maybe?) but I'm sure someone here has done this before. Stuart On 6/6/2016 3:37 AM, Robert Osfield wrote: Hi Stuart, I believe it should be possible to have the FindFreetype.cmake detect that PNG is used and create an additional libraries var or just add it into FREETYPE_LIBRARIES var. Have a look at how the other Free*.cmake modules handle extra dependencies that need to be linked in. If this is done right it should be possible to have the OSG's freetype plugin to work without any special manual settings to add the PNG dependency. Robert. On 5 June 2016 at 22:51, Stuart Mentzer wrote: Hi Robert, OK, I am testing a patched FindFreetype.cmake with OSG now. If that works I'll submit it to CMake and to OSG. If it is better to post it to the osg-submissions list rather than here I can do that but it is then separate from the context of this discussion. It doesn't seem practical for us to fix freetype but I'll file a suggestion with them to reconsider this build approach. For now, with a wiki note on refreshing the source, the only freetype improvement we can benefit from is making osgPlugins/freetype/CMakeLists.txt able to add PNG_LIBRARY (or other freetype optional libs?) to the target libraries if needed. I don't know enough CMake yet to do that automatically and adding a variable to pass to the cmake call seems like cruft. If OSG has no benefit from PNG support in freetype then a note not to enable it is probably the way to go. Cheers, Stuart On 6/5/2016 7:41 AM, Robert Osfield wrote: HI Stuart, It sounds like taking the CMake FindFreetype.cmake modifying to work and then getting this checked over by the cmake community as being suitable for them to merge and then sending the final rev along to me to merge would enable us to roll out the improved support prior to the next CMake release. If the CMake release is made before we push out 3.6 then we wouldn't need to add it locally. With the freetype wiring to PNG+ZLIB, this sounds like the could improve things with their own source/build system. I don't know freetype well enough to know how easy it would be to fix things to make it easier to switch. This type of issue is why the OSG has plugins and NodeKits - the core libraries are kept with minimal dependencies, this way the dependency chain doesn't pollute anything more than it needs to. Robert. On 5 June 2016 at 02:35, Stuart Mentzer wrote: Hi Robert, I have asked the CMake community about updating their FindFreetype.cmake to support Windows debug library naming and I will follow up to try and get that fixed in upcoming releases. I was pointed to how they do it correctly for zlib so I could make a variant of their FindFreetype.cmake for OSG to use until their fix is released. This would retain their support for the old and new include structure. If you'd like me to submit that let me know. Wrt the PNG on/off issue, I now understand the approach they use. The upshot is that as long as you refresh the freetype source tree you are building with from the original code before each build you can switch PNG support on or off in the cmake command with -DWITH_PNG=ON or OFF and without manually editing ftoption.h. (Same holds for ZLIB support.) The reason is that the build goes in and modifies ftoption.h in the source tree (as well as making a copy in the build tree) and the modification only uncomments those defines, so you can't build with PNG enabled and then PNG disabled without refreshing the source first. This is an unfortunate approach but that is what we are stuck with. Most builders don't switch the PNG or ZLIB support on and off so this probably doesn't often trip people up. The best we can probably do is add a note on an appropriate wiki page. I added this refresh step to my build scripts. Stuart On 6/4/2016 3:36 PM, Robert Osfield wrote: Hi Stuart, It sounds like the version of Freestyle is broken or it requires a tweak to configuration. Have you approached the freetype community about these issues. The debug vs release issue is something that would be worth raising with the cake community as it sounds like a revision to their Findfreetype.cmake. Robert On 3 Jun 201
Re: [osg-users] freetype build support on Windows
Hi Robert, If you don't end up making CMake 2.8 the min version then we could just bring select_library_configurations (with a different name) into FindFreetype as a temporary work-around. It is not much code. Stuart On 6/8/2016 11:19 AM, Robert Osfield wrote: Hi Stuart, On 8 June 2016 at 16:11, Stuart Mentzer wrote: Hi Robert, I find a reference to SelectLibraryConfigurations in CMake 2.8 but not 2.6. I don't know what the OSG min CMake version is. In the OpenSceneGraph/CMakeLists.txt we have: IF(WIN32) CMAKE_MINIMUM_REQUIRED(VERSION 2.4.6 FATAL_ERROR) ELSE(WIN32) IF(APPLE) CMAKE_MINIMUM_REQUIRED(VERSION 2.6.0 FATAL_ERROR) ELSE(APPLE) CMAKE_MINIMUM_REQUIRED(VERSION 2.4.4 FATAL_ERROR) ENDIF(APPLE) ENDIF(WIN32) Which means 2.4.4 is the minimum, but.. this wasn't written when we first introduced CMake as a build system for the OSG. Whether we can set 2.8 as a minimum now is something that is different to know without having the whole community chip in. I'll start a separate thread for this calling for feedback. For freetype's PNG dependency I don't know how to do that automatically. Is there someone with good CMake chops we could ask for help? I'm kind of swamped so it could be a while until I can devote some time to figuring this out. I'll have to pass on this as I've got a bucket load of other work to get on with. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] freetype build support on Windows
Hi Robert, I find a reference to SelectLibraryConfigurations in CMake 2.8 but not 2.6. I don't know what the OSG min CMake version is. For freetype's PNG dependency I don't know how to do that automatically. Is there someone with good CMake chops we could ask for help? I'm kind of swamped so it could be a while until I can devote some time to figuring this out. Stuart On 6/8/2016 11:01 AM, Robert Osfield wrote: Hi Stuart, On 8 June 2016 at 15:54, Stuart Mentzer wrote: Hi Robert, I think the call to select_library_configurations might already be doing what you are after but I'm no CMake expert. The code is in CMake's SelectLibraryConfigurations module. Learn something new every day :-) Do you have an idea which version of CMake this feature was added? My concern is that is we make one of out find modules only work with recent versions of CMake then we'll break the build for those stuck with older versions of CMake. What about the PNG dependency, have you resolved a way to detect this and add it in? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] freetype build support on Windows
Hi Robert, I think the call to select_library_configurations might already be doing what you are after but I'm no CMake expert. The code is in CMake's SelectLibraryConfigurations module. If not, I don't see why CMake wouldn't accept this as part of a (revised) patch, with the goal that we can move to the stock FindFreetype module eventually. Stuart On 6/8/2016 10:36 AM, Robert Osfield wrote: Hi Stuart, I have just had a quick look at the FindFreetype.cmake. Looks sensible but it looks to miss an opportunity to automatically set up the debug library. It's possible in CMake to set the FREETYPE_LIBRARIES var to contain both the release and debug builds. It should also be possible to add the PNG library dependency in here as well if it's required. The OpenSceneGraph/CMakeModules/Find3rdPartyDependencies.cmake set it up thus: SET(${DEPNAME}_LIBRARIES debug ${${DEPNAME}_LIBRARY_DEBUG} optimized ${${DEPNAME}_LIBRARY} ) Which can be simplified for Freetype: SET(FREETYPE_LIBRARIES debug FREETYPE_LIBRARY_DEBUG} optimized FREETYPE_LIBRARY} ) One would typically set the _DEBUG up to reference the non debug library when the debug library isn't available. I could potentially check what you have into the OSG and then modify it or you could modify make sure it works on your system then submit for final merge. Robert. On 8 June 2016 at 05:56, Stuart Mentzer wrote: Hi Robert, Sorry for the delay -- it took a few go-rounds to get this in the shape that CMake folks wanted it. This is what I have submitted to CMake with a few necessary tweaks: . Full copyright text that they require when not shipped with CMake . include statement tweak to work when not within CMake If you want this to go the osg-submissions let me know. This missed the CMake 3.6 freeze so it probably won't be released for a bit but this version should hold us until then. I'll try to remember to check for the patch in future CMake releases and let you know when the custom version is no longer required. Wrt the freetype build, it seems they have already eliminated the build modifying headers in the source tree (or the need to copy the changes into it) and I confirmed that with freetype 2.6.3. So as long as we assume OSG 3rd party lib builders are using fresh lib versions we don't need a wiki note about that gotcha. Cheers, Stuart On 6/5/2016 7:41 AM, Robert Osfield wrote: HI Stuart, It sounds like taking the CMake FindFreetype.cmake modifying to work and then getting this checked over by the cmake community as being suitable for them to merge and then sending the final rev along to me to merge would enable us to roll out the improved support prior to the next CMake release. If the CMake release is made before we push out 3.6 then we wouldn't need to add it locally. With the freetype wiring to PNG+ZLIB, this sounds like the could improve things with their own source/build system. I don't know freetype well enough to know how easy it would be to fix things to make it easier to switch. This type of issue is why the OSG has plugins and NodeKits - the core libraries are kept with minimal dependencies, this way the dependency chain doesn't pollute anything more than it needs to. Robert. On 5 June 2016 at 02:35, Stuart Mentzer wrote: Hi Robert, I have asked the CMake community about updating their FindFreetype.cmake to support Windows debug library naming and I will follow up to try and get that fixed in upcoming releases. I was pointed to how they do it correctly for zlib so I could make a variant of their FindFreetype.cmake for OSG to use until their fix is released. This would retain their support for the old and new include structure. If you'd like me to submit that let me know. Wrt the PNG on/off issue, I now understand the approach they use. The upshot is that as long as you refresh the freetype source tree you are building with from the original code before each build you can switch PNG support on or off in the cmake command with -DWITH_PNG=ON or OFF and without manually editing ftoption.h. (Same holds for ZLIB support.) The reason is that the build goes in and modifies ftoption.h in the source tree (as well as making a copy in the build tree) and the modification only uncomments those defines, so you can't build with PNG enabled and then PNG disabled without refreshing the source first. This is an unfortunate approach but that is what we are stuck with. Most builders don't switch the PNG or ZLIB support on and off so this probably doesn't often trip people up. The best we can probably do is add a note on an appropriate wiki page. I added this refresh step to my build scripts. Stuart On 6/4/2016 3:36 PM, Robert Osfield wrote: Hi Stuart, It sounds like the version of Freestyle is broken or it requires a tweak to configuration. Have you approached the freetype community about these issues. The debug vs release issue
Re: [osg-users] freetype build support on Windows
To clarify, the issues arise not in building freetype but in building the freetype plugin. The OSG FindFreetype.cmake module has two issues: 1. The debug library is named freetyped.lib (not freetype.lib) and the NAMES variable doesn't have freetyped so it isn't found in a debug build. (This is also a flaw in CMake's FindFreetype module and I have submitted a patch.) 2. The include directory structure in freetype 2.6.3 is different than what FindFreetype.cmake expects. If you are getting the freetype plugin built with freetype 2.6.3 or in a debug build using the stock OSG FindFreetype.cmake then that is a mystery. You could work around the first issue by setting the library variable externally I guess. I have not looked at Björn's scripts -- I developed my own that handle the whole build also. Stuart On 6/6/2016 4:33 AM, Carl-Gustaf Kung wrote: I don't know if I missunderstand your original post somehow, but I did build freetype twice in last few days with no issues whatsoever. I am on windows 10 64-bit and I have built it with VS2015 Community Edition, both debug and release libs. If you use cmake file that comes with freetype from git, just comment out check for mingw and shared libs: #if (WIN32 AND NOT MINGW AND BUILD_SHARED_LIBS) # message(FATAL_ERROR "Building shared libraries on Windows needs MinGW") #endif () If you use Björn's cmake scripts, you have to do nothing. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=67437#67437 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] freetype build support on Windows
Hi Robert, If we do this in FindFreetype.cmake it will prevent us from using CMake's version (once the patch goes in). So that means doing it in the CMakeLists.txt for the freetype plugin. Anyway, I don't know enough CMake to find another package's dependencies (something with pkg_config maybe?) but I'm sure someone here has done this before. Stuart On 6/6/2016 3:37 AM, Robert Osfield wrote: Hi Stuart, I believe it should be possible to have the FindFreetype.cmake detect that PNG is used and create an additional libraries var or just add it into FREETYPE_LIBRARIES var. Have a look at how the other Free*.cmake modules handle extra dependencies that need to be linked in. If this is done right it should be possible to have the OSG's freetype plugin to work without any special manual settings to add the PNG dependency. Robert. On 5 June 2016 at 22:51, Stuart Mentzer wrote: Hi Robert, OK, I am testing a patched FindFreetype.cmake with OSG now. If that works I'll submit it to CMake and to OSG. If it is better to post it to the osg-submissions list rather than here I can do that but it is then separate from the context of this discussion. It doesn't seem practical for us to fix freetype but I'll file a suggestion with them to reconsider this build approach. For now, with a wiki note on refreshing the source, the only freetype improvement we can benefit from is making osgPlugins/freetype/CMakeLists.txt able to add PNG_LIBRARY (or other freetype optional libs?) to the target libraries if needed. I don't know enough CMake yet to do that automatically and adding a variable to pass to the cmake call seems like cruft. If OSG has no benefit from PNG support in freetype then a note not to enable it is probably the way to go. Cheers, Stuart On 6/5/2016 7:41 AM, Robert Osfield wrote: HI Stuart, It sounds like taking the CMake FindFreetype.cmake modifying to work and then getting this checked over by the cmake community as being suitable for them to merge and then sending the final rev along to me to merge would enable us to roll out the improved support prior to the next CMake release. If the CMake release is made before we push out 3.6 then we wouldn't need to add it locally. With the freetype wiring to PNG+ZLIB, this sounds like the could improve things with their own source/build system. I don't know freetype well enough to know how easy it would be to fix things to make it easier to switch. This type of issue is why the OSG has plugins and NodeKits - the core libraries are kept with minimal dependencies, this way the dependency chain doesn't pollute anything more than it needs to. Robert. On 5 June 2016 at 02:35, Stuart Mentzer wrote: Hi Robert, I have asked the CMake community about updating their FindFreetype.cmake to support Windows debug library naming and I will follow up to try and get that fixed in upcoming releases. I was pointed to how they do it correctly for zlib so I could make a variant of their FindFreetype.cmake for OSG to use until their fix is released. This would retain their support for the old and new include structure. If you'd like me to submit that let me know. Wrt the PNG on/off issue, I now understand the approach they use. The upshot is that as long as you refresh the freetype source tree you are building with from the original code before each build you can switch PNG support on or off in the cmake command with -DWITH_PNG=ON or OFF and without manually editing ftoption.h. (Same holds for ZLIB support.) The reason is that the build goes in and modifies ftoption.h in the source tree (as well as making a copy in the build tree) and the modification only uncomments those defines, so you can't build with PNG enabled and then PNG disabled without refreshing the source first. This is an unfortunate approach but that is what we are stuck with. Most builders don't switch the PNG or ZLIB support on and off so this probably doesn't often trip people up. The best we can probably do is add a note on an appropriate wiki page. I added this refresh step to my build scripts. Stuart On 6/4/2016 3:36 PM, Robert Osfield wrote: Hi Stuart, It sounds like the version of Freestyle is broken or it requires a tweak to configuration. Have you approached the freetype community about these issues. The debug vs release issue is something that would be worth raising with the cake community as it sounds like a revision to their Findfreetype.cmake. Robert On 3 Jun 2016 11:24 p.m., "Stuart Mentzer" wrote: Hi Robert, Here's what I found doing release and debug builds from yersterday's git master code with Visual C++ 2015: freetype even using -DWITH_PNG=OFF will still try to include png.h and for some reason requires ftoption.h (both copies) to be modified (or overridden) to comment out the line: #define FT_CONFIG_OPTION_USE_PNG This is unfortunate and actually makes it easier
Re: [osg-users] freetype build support on Windows
Hi Robert, Sorry for the delay -- it took a few go-rounds to get this in the shape that CMake folks wanted it. This is what I have submitted to CMake with a few necessary tweaks: . Full copyright text that they require when not shipped with CMake . include statement tweak to work when not within CMake If you want this to go the osg-submissions let me know. This missed the CMake 3.6 freeze so it probably won't be released for a bit but this version should hold us until then. I'll try to remember to check for the patch in future CMake releases and let you know when the custom version is no longer required. Wrt the freetype build, it seems they have already eliminated the build modifying headers in the source tree (or the need to copy the changes into it) and I confirmed that with freetype 2.6.3. So as long as we assume OSG 3rd party lib builders are using fresh lib versions we don't need a wiki note about that gotcha. Cheers, Stuart On 6/5/2016 7:41 AM, Robert Osfield wrote: HI Stuart, It sounds like taking the CMake FindFreetype.cmake modifying to work and then getting this checked over by the cmake community as being suitable for them to merge and then sending the final rev along to me to merge would enable us to roll out the improved support prior to the next CMake release. If the CMake release is made before we push out 3.6 then we wouldn't need to add it locally. With the freetype wiring to PNG+ZLIB, this sounds like the could improve things with their own source/build system. I don't know freetype well enough to know how easy it would be to fix things to make it easier to switch. This type of issue is why the OSG has plugins and NodeKits - the core libraries are kept with minimal dependencies, this way the dependency chain doesn't pollute anything more than it needs to. Robert. On 5 June 2016 at 02:35, Stuart Mentzer wrote: Hi Robert, I have asked the CMake community about updating their FindFreetype.cmake to support Windows debug library naming and I will follow up to try and get that fixed in upcoming releases. I was pointed to how they do it correctly for zlib so I could make a variant of their FindFreetype.cmake for OSG to use until their fix is released. This would retain their support for the old and new include structure. If you'd like me to submit that let me know. Wrt the PNG on/off issue, I now understand the approach they use. The upshot is that as long as you refresh the freetype source tree you are building with from the original code before each build you can switch PNG support on or off in the cmake command with -DWITH_PNG=ON or OFF and without manually editing ftoption.h. (Same holds for ZLIB support.) The reason is that the build goes in and modifies ftoption.h in the source tree (as well as making a copy in the build tree) and the modification only uncomments those defines, so you can't build with PNG enabled and then PNG disabled without refreshing the source first. This is an unfortunate approach but that is what we are stuck with. Most builders don't switch the PNG or ZLIB support on and off so this probably doesn't often trip people up. The best we can probably do is add a note on an appropriate wiki page. I added this refresh step to my build scripts. Stuart On 6/4/2016 3:36 PM, Robert Osfield wrote: Hi Stuart, It sounds like the version of Freestyle is broken or it requires a tweak to configuration. Have you approached the freetype community about these issues. The debug vs release issue is something that would be worth raising with the cake community as it sounds like a revision to their Findfreetype.cmake. Robert On 3 Jun 2016 11:24 p.m., "Stuart Mentzer" wrote: Hi Robert, Here's what I found doing release and debug builds from yersterday's git master code with Visual C++ 2015: freetype even using -DWITH_PNG=OFF will still try to include png.h and for some reason requires ftoption.h (both copies) to be modified (or overridden) to comment out the line: #define FT_CONFIG_OPTION_USE_PNG This is unfortunate and actually makes it easier to build freetype with PNG support. With the freetype mods OSG builds including the freetype plugin. Configuring freetype with or without PNG support is up to the builder but it would be good if the CMakeLists.txt could handle both situations without needing changes like I made. The freetype build headers under include\freetype2\freetype even though freetype doesn't use that freetype2 layer anymore. Not a big deal since OSG doesn't really need to ship with freetype or other 3rd party lib headers. The debug build is able to build freetype with the same mods but the OSG build doesn't find it: -- Could NOT find Freetype (missing: FREETYPE_LIBRARY) (found version "2.6.3") which I assume is due to not looking for the name freetyped, as I found with my OSG 3.4.0 build. So the OSG build can complete but it won't
Re: [osg-users] freetype build support on Windows
Hi Robert, OK, I am testing a patched FindFreetype.cmake with OSG now. If that works I'll submit it to CMake and to OSG. If it is better to post it to the osg-submissions list rather than here I can do that but it is then separate from the context of this discussion. It doesn't seem practical for us to fix freetype but I'll file a suggestion with them to reconsider this build approach. For now, with a wiki note on refreshing the source, the only freetype improvement we can benefit from is making osgPlugins/freetype/CMakeLists.txt able to add PNG_LIBRARY (or other freetype optional libs?) to the target libraries if needed. I don't know enough CMake yet to do that automatically and adding a variable to pass to the cmake call seems like cruft. If OSG has no benefit from PNG support in freetype then a note not to enable it is probably the way to go. Cheers, Stuart On 6/5/2016 7:41 AM, Robert Osfield wrote: HI Stuart, It sounds like taking the CMake FindFreetype.cmake modifying to work and then getting this checked over by the cmake community as being suitable for them to merge and then sending the final rev along to me to merge would enable us to roll out the improved support prior to the next CMake release. If the CMake release is made before we push out 3.6 then we wouldn't need to add it locally. With the freetype wiring to PNG+ZLIB, this sounds like the could improve things with their own source/build system. I don't know freetype well enough to know how easy it would be to fix things to make it easier to switch. This type of issue is why the OSG has plugins and NodeKits - the core libraries are kept with minimal dependencies, this way the dependency chain doesn't pollute anything more than it needs to. Robert. On 5 June 2016 at 02:35, Stuart Mentzer wrote: Hi Robert, I have asked the CMake community about updating their FindFreetype.cmake to support Windows debug library naming and I will follow up to try and get that fixed in upcoming releases. I was pointed to how they do it correctly for zlib so I could make a variant of their FindFreetype.cmake for OSG to use until their fix is released. This would retain their support for the old and new include structure. If you'd like me to submit that let me know. Wrt the PNG on/off issue, I now understand the approach they use. The upshot is that as long as you refresh the freetype source tree you are building with from the original code before each build you can switch PNG support on or off in the cmake command with -DWITH_PNG=ON or OFF and without manually editing ftoption.h. (Same holds for ZLIB support.) The reason is that the build goes in and modifies ftoption.h in the source tree (as well as making a copy in the build tree) and the modification only uncomments those defines, so you can't build with PNG enabled and then PNG disabled without refreshing the source first. This is an unfortunate approach but that is what we are stuck with. Most builders don't switch the PNG or ZLIB support on and off so this probably doesn't often trip people up. The best we can probably do is add a note on an appropriate wiki page. I added this refresh step to my build scripts. Stuart On 6/4/2016 3:36 PM, Robert Osfield wrote: Hi Stuart, It sounds like the version of Freestyle is broken or it requires a tweak to configuration. Have you approached the freetype community about these issues. The debug vs release issue is something that would be worth raising with the cake community as it sounds like a revision to their Findfreetype.cmake. Robert On 3 Jun 2016 11:24 p.m., "Stuart Mentzer" wrote: Hi Robert, Here's what I found doing release and debug builds from yersterday's git master code with Visual C++ 2015: freetype even using -DWITH_PNG=OFF will still try to include png.h and for some reason requires ftoption.h (both copies) to be modified (or overridden) to comment out the line: #define FT_CONFIG_OPTION_USE_PNG This is unfortunate and actually makes it easier to build freetype with PNG support. With the freetype mods OSG builds including the freetype plugin. Configuring freetype with or without PNG support is up to the builder but it would be good if the CMakeLists.txt could handle both situations without needing changes like I made. The freetype build headers under include\freetype2\freetype even though freetype doesn't use that freetype2 layer anymore. Not a big deal since OSG doesn't really need to ship with freetype or other 3rd party lib headers. The debug build is able to build freetype with the same mods but the OSG build doesn't find it: -- Could NOT find Freetype (missing: FREETYPE_LIBRARY) (found version "2.6.3") which I assume is due to not looking for the name freetyped, as I found with my OSG 3.4.0 build. So the OSG build can complete but it won't build the freetype plugin. The debug build fails at "Installing
Re: [osg-users] freetype build support on Windows
Hi Robert, I have asked the CMake community about updating their FindFreetype.cmake to support Windows debug library naming and I will follow up to try and get that fixed in upcoming releases. I was pointed to how they do it correctly for zlib so I could make a variant of their FindFreetype.cmake for OSG to use until their fix is released. This would retain their support for the old and new include structure. If you'd like me to submit that let me know. Wrt the PNG on/off issue, I now understand the approach they use. The upshot is that as long as you refresh the freetype source tree you are building with from the original code before each build you can switch PNG support on or off in the cmake command with -DWITH_PNG=ON or OFF and without manually editing ftoption.h. (Same holds for ZLIB support.) The reason is that the build goes in and modifies ftoption.h in the source tree (as well as making a copy in the build tree) and the modification only uncomments those defines, so you can't build with PNG enabled and then PNG disabled without refreshing the source first. This is an unfortunate approach but that is what we are stuck with. Most builders don't switch the PNG or ZLIB support on and off so this probably doesn't often trip people up. The best we can probably do is add a note on an appropriate wiki page. I added this refresh step to my build scripts. Stuart On 6/4/2016 3:36 PM, Robert Osfield wrote: Hi Stuart, It sounds like the version of Freestyle is broken or it requires a tweak to configuration. Have you approached the freetype community about these issues. The debug vs release issue is something that would be worth raising with the cake community as it sounds like a revision to their Findfreetype.cmake. Robert On 3 Jun 2016 11:24 p.m., "Stuart Mentzer" <osgfo...@tevs.eu> wrote: Hi Robert, Here's what I found doing release and debug builds from yersterday's git master code with Visual C++ 2015: freetype even using -DWITH_PNG=OFF will still try to include png.h and for some reason requires ftoption.h (both copies) to be modified (or overridden) to comment out the line: #define FT_CONFIG_OPTION_USE_PNG This is unfortunate and actually makes it easier to build freetype with PNG support. With the freetype mods OSG builds including the freetype plugin. Configuring freetype with or without PNG support is up to the builder but it would be good if the CMakeLists.txt could handle both situations without needing changes like I made. The freetype build headers under include\freetype2\freetype even though freetype doesn't use that freetype2 layer anymore. Not a big deal since OSG doesn't really need to ship with freetype or other 3rd party lib headers. The debug build is able to build freetype with the same mods but the OSG build doesn't find it: -- Could NOT find Freetype (missing: FREETYPE_LIBRARY) (found version "2.6.3") which I assume is due to not looking for the name freetyped, as I found with my OSG 3.4.0 build. So the OSG build can complete but it won't build the freetype plugin. The debug build fails at "Installing the project..." because it appears something is wrong with the new pdb installation support: -- Installing: C:/OSG.VC.xd/bin/osgd.dll CMake Error at src/osg/cmake_install.cmake:39 (file): file INSTALL cannot find "C:/Projects/OSG/VC.xd/OSG/src/osg/PREFIX-NOTFOUNDosgd.pdb". Call Stack (most recent call first): src/cmake_install.cmake:33 (include) cmake_install.cmake:100 (include) The osgd.pdb file is present and next to osgd.dll as expected. I see that others are reporting success with the Visual C++ 2015 build but I don't know how they are addressing the freetype PNG issues or if they tried the debug build yet. It looks like there are still some issues but maybe they will offer some input here. I'm happy to make another pass if that helps. Stuart -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=67406#67406 ___ osg-users mailing list
Re: [osg-users] freetype build support on Windows
Hi Robert, Here's what I found doing release and debug builds from yersterday's git master code with Visual C++ 2015: freetype even using -DWITH_PNG=OFF will still try to include png.h and for some reason requires ftoption.h (both copies) to be modified (or overridden) to comment out the line: #define FT_CONFIG_OPTION_USE_PNG This is unfortunate and actually makes it easier to build freetype with PNG support. With the freetype mods OSG builds including the freetype plugin. Configuring freetype with or without PNG support is up to the builder but it would be good if the CMakeLists.txt could handle both situations without needing changes like I made. The freetype build headers under include\freetype2\freetype even though freetype doesn't use that freetype2 layer anymore. Not a big deal since OSG doesn't really need to ship with freetype or other 3rd party lib headers. The debug build is able to build freetype with the same mods but the OSG build doesn't find it: -- Could NOT find Freetype (missing: FREETYPE_LIBRARY) (found version "2.6.3") which I assume is due to not looking for the name freetyped, as I found with my OSG 3.4.0 build. So the OSG build can complete but it won't build the freetype plugin. The debug build fails at "Installing the project..." because it appears something is wrong with the new pdb installation support: -- Installing: C:/OSG.VC.xd/bin/osgd.dll CMake Error at src/osg/cmake_install.cmake:39 (file): file INSTALL cannot find "C:/Projects/OSG/VC.xd/OSG/src/osg/PREFIX-NOTFOUNDosgd.pdb". Call Stack (most recent call first): src/cmake_install.cmake:33 (include) cmake_install.cmake:100 (include) The osgd.pdb file is present and next to osgd.dll as expected. I see that others are reporting success with the Visual C++ 2015 build but I don't know how they are addressing the freetype PNG issues or if they tried the debug build yet. It looks like there are still some issues but maybe they will offer some input here. I'm happy to make another pass if that helps. Stuart -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=67406#67406 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] freetype build support on Windows
Hi Robert, This is a bit of a head-scratcher but even when building freetype ostensibly without PNG support (-DWITH_PNG=OFF) I am still getting those unresolved png errors. It seems to trace back to the #define FT_CONFIG_OPTION_USE_PNG in ftoption.h that isn't commented out in the configured/build when PNG support is disabled. I'm not sure what is different on Linux builds that avoids this. I can look into this further but maybe someone here knows what the story is. I'm sure we don't want to require freetype code to be hacked to build OSG. I don't see a variable in CMake's FindFreetype.cmake for additional libraries but it is aimed at finding freetype so that isn't surprising. My addition for the PNG lib was in: SET(TARGET_LIBRARIES_VARS FREETYPE_LIBRARY PNG_LIBRARY ) in the freetype CMakeLists.txt so that is probably where we'd need to add flexibility for PNG and that doesn't preclude use of CMake's FindFreetype.cmake. I hit another issue: If I put 3rdparty\include in the VC++ INCLUDE env var and it has the unistd.h from giflib that breaks the build. Easy enough to fix by leaving that header out but I'm wondering if it is standard practice to put 3rdparty\include on the include search path. I didn't need it before but when I build freetype using -DWITH_PNG=OFF it still wants to include png.h (maybe another symptom of the first problem) so I tried to get beyond that by adding it to the include search path. I'll dig further and see what I can find out... Stuart -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=67365#67365 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] freetype build support on Windows
robertosfield wrote: > Could you please try a build with the latest that I've checked in and > see what happens. Trying with Visual C++ 2015... I've been enabling PNG support in my freetype lib build (-DWITH_PNG=ON) and this causes unresolved png symbols when linking osgdb_freetype.dll since I'm enabling PNG support : Code: [ 94%] Linking CXX shared module osgdb_freetype.dll freetype.lib(sfnt.c.obj) : error LNK2019: unresolved external symbol png_create_read_struct referenced in function Load_SBit_Png freetype.lib(sfnt.c.obj) : error LNK2019: unresolved external symbol png_set_longjmp_fn referenced in function Load_SBit_Png ... osgdb_freetype.dll : fatal error LNK1120: 23 unresolved externals This is why I made that PNG change in my submission code. I don't know if we want/need to support PNG in freetype for OSG purposes but for now I'll try again with it disabled and let you know what happens. BTW I also see a lot of base class initialization warnings: Code: C:\Projects\OSG\OpenSceneGraph\include\osg/OperationThread(80): warning C4589: Constructor of abstract class 'osg::Operation' ignores initializer for virtual base class 'osg::Referenced' C:\Projects\OSG\OpenSceneGraph\include\osg/OperationThread(80): note: virtual base classes are only initialized by the most-derived type C:\Projects\OSG\OpenSceneGraph\include\osg/OperationThread(84): warning C4589: Constructor of abstract class 'osg::Operation' ignores initializer for virtual base class 'osg::Referenced' C:\Projects\OSG\OpenSceneGraph\include\osg/OperationThread(84): note: virtual base classes are only initialized by the most-derived type There were other warnings that may be meaningful when I built 3.4.0. If it would be helpful to work towards reducing them I'm willing to give it some time. Stuart -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=67347#67347 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] freetype build support on Windows
Hi Robert, While trying to get past build problems I did try using CMake's FindFreetype.cmake and it didn't work so I suspect you are correct that some other changes will be required. It does look like the CMake version is at least attempting to cover the various freetype layouts so it could eliminate an OSG maintenance burden. But its find_library doesn't have freetyped so I don't know if it solves the debug build issue unless we can do it by setting FREETYPE_LIBRARY. Stuart On 6/1/2016 11:05 AM, Robert Osfield wrote: Hi Stuart, I have now checked in my changes to build the OSG using CMake's FindFreetype.cmake rather than the OSG's native one, I deleted the later as well as change the src/osgPlugins/freetype/CmakeListst.txt. I have tested this under Kubuntu 16.04 so far. After checking the changes in I am now starting to think that using the standard Windows 3rd party depdencies package and the associated Find3rdPartyDependencies.cmake might not set up the variables in the same way as CMake's FindFreetype.cmake so could lead to problems. In particular I don't think the FREETYPE_LIBRARIES var usage that I've introduced will work with the Find3rdPartyDependencies.cmake that will be just setting the FREETYPE_LIBRARY var. I think Find3rdPartyDependencies.cmake should be creating a FREETYPE_LIBRARIES var as well, but am not a CMake guru so will need to look up the rules for doing this. Robert. On 1 June 2016 at 15:23, Robert Osfield wrote: Hi Stuart, Thanks for the modified file. I've just reviewed this, as is it would break the build for others as you remove paths from the search list rather than just add a new one. The addition of the debug library is desirable but would raise the issue of mixing debug and release libs, something that the present ones do in the opposite direction so the original script isn't ideal on this either. I can easily insert your additions into the OSG's FindFreetype.cmake, however, I do wonder if it's not best now to just adopt CMake's own FindFreetype.cmake. CMake has come along way since the early days when we adopted and it's own list of Find scripts was lacking. I will have a bash with removing the OSG's FindFreetype.cmake so the it utilizes CMake own version, if this works well I'll check it in to git master. On 1 June 2016 at 11:54, Stuart Mentzer wrote: Hi, [I know this is more of a build issue but I was asked to bring this here to get a wider swath of OSG experts.] I am doing Windows builds with VC++ 2015 and latest build from sources of the 3rd party libraries. A few issues with the current freetype lib cause the build to fail and we want to get the right patches to support different versions of freetype. The 2 issues are: The include path structure doesn't have a freeetype2 directory anymore so the stock FindFreetype.cmake isn't working. In the attached FindFreetype.cmake I just hacked it to work with the new layout but that obviously won't work for the old layout. Does some CMake guru know the right way to do this? Would it work to just drop the OSG custom FindFreetype.cmake and use the CMake one (which seems to have both include/freetype2 and include supported in the latest CMake)? The debug build doesn't find freetyped.lib because freetyped isn't in the NAMES list. I added freetyped to NAMES but if that isn't the right/safe way to do it it would be helpful to hear a better idea. Thank you! Cheers, Stuart[/list] -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=67315#67315 Attachments: http://forum.openscenegraph.org//files/findfreetypecmake_210.txt ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] freetype build support on Windows
Hi, [I know this is more of a build issue but I was asked to bring this here to get a wider swath of OSG experts.] I am doing Windows builds with VC++ 2015 and latest build from sources of the 3rd party libraries. A few issues with the current freetype lib cause the build to fail and we want to get the right patches to support different versions of freetype. The 2 issues are: The include path structure doesn't have a freeetype2 directory anymore so the stock FindFreetype.cmake isn't working. In the attached FindFreetype.cmake I just hacked it to work with the new layout but that obviously won't work for the old layout. Does some CMake guru know the right way to do this? Would it work to just drop the OSG custom FindFreetype.cmake and use the CMake one (which seems to have both include/freetype2 and include supported in the latest CMake)? The debug build doesn't find freetyped.lib because freetyped isn't in the NAMES list. I added freetyped to NAMES but if that isn't the right/safe way to do it it would be helpful to hear a better idea. Thank you! Cheers, Stuart[/list] -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=67315#67315 Attachments: http://forum.openscenegraph.org//files/findfreetypecmake_210.txt ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [ANN] Windows Binaries of OSG 3.4.0 : Visual C++ 2015 and Intel C++ 2016
Chris Hanson wrote: > Hey Stuart, we should coordinate. Sure. I'll email you directly for parts of the discussion that won't be of general interest. Since the first info I posted for you I have got the builds scripted after the initial CMake setup tweaks. Stuart -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=67019#67019 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [ANN] Windows Binaries of OSG 3.4.0 : Visual C++ 2015 and Intel C++ 2016
Hi Sebastian, SMesserschmidt wrote: > Can you elaborate on the specific versions used for the 3rd-party libraries? > Especially if you compiled against Qt and possibly which version. I built against Qt 5.6 and osgQt was built. I used the latest version of dependencies: curl 7.48.0 freetype 2.6.3 giflib 5.1.4 glut 3.7 libjpeg 9b libpng 1.6.21 libtiff 4.0.6 minizip GitHub tip zlib 1.2.8 > Interesting, can you point to some sources why the /fp:fast is needed > for auto-vectorization? I'm pretty sure I've seen at least SSE2 > vectorization on some meta-programming matrix code of mine. Precision > is a real issue for me, so forgive my skepticism. Yes, it is hard to find the documentation on this. The "fast" option is required for floating point loops to fully auto-vectorize because vectorization can reorder operations, thus breaking strict IEEE rules. Similarly, if you put #pragma simd on a loop it will enable "fast" for you. A reference for this with VC++ is: https://blogs.msdn.microsoft.com/vcblog/2015/10/19/do-you-prefer-fast-or-precise/ (see A7. Auto-Vectorization) For Intel C++ one reference is the comment by Tim P. (who knows Intel compilers) in: https://software.intel.com/en-us/forums/intel-c-compiler/topic/508146 where he says "/fp: options other than fast prevent vectorization which depends on optimizing order of operations" It is probably most accurate to say that some vectorization is possible without the "fast" options but avoiding associativity limits vectorization. I'm not sure if /fp:fast=1 gives the full auto-vectorization with less precision loss. It would be good to have an option that allows reordering for loop vectorization but still uses the full precision math library calls, but I don't think that exists. I get the sensitivity to precision, which is why I'm trying to indicate that this first Intel C++ build is sort of experimental. Once we give it a workout and see the positive and negative effects of various options we'll know better what build variations are worth providing. Regards, Stuart -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=67017#67017 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [ANN] Windows Binaries of OSG 3.4.0 : Visual C++ 2015 and Intel C++ 2016
Hello dear OSG-community, OSG 3.4.0 Windows binaries built with Visual C++ 2015 and Intel C++ 2016 are now available from this page on my company's site: http://objexx.com/OpenSceneGraph.html A ReadMe.txt file in the root directory of the expanded package has some details. These are 64-bit builds with the default GL2 OpenGL level and these dependencies: curl, freetype, giflib, glut, jpeg, lpng, minizip, tiff, zlib. We can add other plugins (GDAL, Collada, ...) based on community interest. There is a vanilla VC++ build and also builds optimized for AVX2 (Haswell and later) CPUs. We are going to do some performance comparisons to see if the AVX2 and/or Intel C++ are beneficial for our application: we also welcome feedback on performance from the community. The Intel C++ build should be binary compatible with VC++ 2015 so you don't need Intel C++ to use it. Note that it was built with /fp:fast=2 to enable auto-vectorization of floating point loops: this could cause small precision loss that might matter with larger/geo distance scales. If vectorization isn't significant/beneficial this option may be dropped: input on this is welcomed. We hope to do some OSG profiling and experiment with tuning on the Windows side with VTune: if we find anything interesting we'll post it on our OSG page and submit code back to the developers. We don't have a need for 32-bit builds or older compilers but feel free to ask ;) . Since we need these ourselves we plan to post binaries for future OSG and compiler releases as a way to give back to the OSG community. Best regards, Stuart -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=67012#67012 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] OSG 3.4.0 Build with Visual C++ 2015
Hi Chris, Here's what I've got. You probably need to adjust the bat for your PATH setup. It isn't polished for general use yet so let me know if you have questions. I have only verified it with osgviewer so far: VC++ is (still!) too broken for MI + covariant returns to build my application so I have to refactor a bit before I can go further. [The batch file is embedded in the text: most email systems block bat files.] Stuart -- Stuart G Mentzer Objexx Engineering Office 1.781.455.1150 x11 Mobile 1.781.708.3872 On 4/20/2016 5:23 PM, Chris Hanson wrote: Stuart, I am about to build OSG with VS2015 Community. Is your build cookbook available somewhere so I'm not reinventing the wheel? ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org OSG VC++ 2015 Build on Windows Notes: mcd is a script for md then cd A subset of optional dependencies was used for this first try cmake.VC.r.bat: (installs OSG to C:\OSG) (without /arch arg for build that works on generic CPU) @echo off setlocal set PATH=C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\bin;C:\MinGW\bin;C:\Git\cmd;C:\CMake\bin set INCLUDE= set LIB= set LIBPATH= call setVC14.64.bat set CC=cl set CXX=cl del CMakeCache.txt >nul 2>nul C:\CMake\bin\cmake.exe -G "MinGW Makefiles" -DCMAKE_COLOR_MAKEFILE:BOOL=0 -DCMAKE_INSTALL_PREFIX="C:/OSG" -DCMAKE_BUILD_TYPE=RELEASE -DCMAKE_CXX_FLAGS_RELEASE="/nologo /EHsc /DNOMINMAX /DWIN32_LEAN_AND_MEAN /DNDEBUG /O2 /GS- /MD" -DCMAKE_C_FLAGS_RELEASE="/nologo /EHsc /DNOMINMAX /DWIN32_LEAN_AND_MEAN /DNDEBUG /O2 /GS- /MD" %* make -j%NUMBER_OF_PROCESSORS% VERBOSE=true make install endlocal zlib: mcd zlib_build ..\cmake.VC.r.bat ../zlib copy zconf.h ..\zlib minizip: (after zlib) option(USE_AES "enables building of aes library" OFF) mcd minizip_build ..\cmake.VC.r.bat -DZLIB_LIBRARY:FILEPATH="../zlib_build/zlib.lib" -DZLIB_INCLUDE_DIR:PATH="../zlib" ../minizip curl: option(CURL_STATICLIB "Set to ON to build libcurl with static linking." ON) mcd curl_build ..\cmake.VC.r.bat ../curl freetype: mcd freetype_build ..\cmake.VC.r.bat /I ../freetype giflib: copy osg-3rdparty-cmake\giflib\* giflib mcd giflib_build ..\cmake.VC.r.bat -DGIFLIB_SOURCE_DIR:PATH="../giflib" -DSKIP_INSTALL_ALL=1 ../giflib glut: copy osg-3rdparty-cmake\glut\* glut mcd glut_build ..\cmake.VC.r.bat -DGLUT_SOURCE_DIR:PATH="../glut" -DSKIP_INSTALL_ALL=1 ../glut jpeg: copy osg-3rdparty-cmake\libjpeg\* jpeg mcd jpeg_build ..\cmake.VC.r.bat -DLIBJPEG_SOURCE_DIR:PATH="../jpeg" -DSKIP_INSTALL_ALL=1 ../jpeg lpng: (after zlib) mcd lpng_build ..\cmake.VC.r.bat -DZLIB_INCLUDE_DIR:PATH="../zlib" -DZLIB_LIBRARY:FILEPATH="../zlib_build/zlib" -DPNG_STATIC=1 ../lpng tiff: mcd tiff_build ..\cmake.VC.r.bat -DCMAKE_PREFIX_PATH:PATH=".." ../tiff (not finding zlib, jpeg, ... packages) Collect all 3rd party libraries in 3rdparty\lib directory and rename them: freetype.lib giflib.lib glut32.lib jpeg.lib libcurl.lib libcurl.dll libcurl.dll.manifest libpng16.lib(rename from libpng16_static.lib) libpng16.dll libpng16.dll.manifest minizip.lib tiff.lib tiff.dll tiff.dll.manifest zlib.lib Collect all 3rd party library headers in 3rdparty\include OSG: Put OSG 3.4.0 source in OSG directory Top-level CMakeLists.txt: IF(MSVC) block (Use newest Windows Kits directory): # Objexx set(CMAKE_STATIC_LINKER_FLAGS "${CMAKE_STATIC_LINKER_FLAGS} /LIBPATH:\"C:/Program Files (x86)/Windows Kits/10/Lib/10.0.10586.0/um/x64\"" CACHE INTERNAL "" FORCE) set(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} /LIBPATH:\"C:/Program Files (x86)/Windows Kits/10/Lib/10.0.10586.0/um/x64\"" CACHE INTERNAL "" FORCE) set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} /LIBPATH:\"C:/Program Files (x86)/Windows Kits/10/Lib/10.0.10586.0/um/x64\"" CACHE INTERNAL "" FORCE) include_directories(AFTER "C:/Projects/OSG/freetype/include") Enable packages on this line and add C:\CMake\bin to PATH so cpack is found: OPTION(BUILD_OSG_PACKAGES "Set to ON to generate CPack configuration files and packaging targets" ON) mcd OSG_build ..\cmake.VC.r.bat ../OSG___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] OSG 3.4.0 Build with Visual C++ 2015
Thanks Sebastian. Good reminder about /arch:AVX2. I can post a separate binary package built with this for people with newer CPUs if it shows a good performance gain. I'll also experiment with /fp:fast and see what the performance gain is, but it sounds like it might not be a good idea for an OSG distribution package. I'll try to get the Intel C++ builds working and I'll report back if I have any interesting findings. The docs claim binary compatibility with VC++ 2015 with /Qvc14. If there is interest in the CMake additions to support Intel C++ I can push them to a GitHub branch. If anyone can point me to good performance benchmarks that would be helpful in sorting out the VC++ and Intel C++ options and performance. Thanks, Stuart -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=66861#66861 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [build] OSG 3.4.0 Build with Visual C++ 2015
Hi, After some struggle I have managed to make a cookbook for building OSG with Visual C++ 2015. This is very exciting because I should finally be able to build our structural impact modeling application on Windows. There are a few items that would be great to get some feedback on: For best (release build) performance would it make sense to use /fp:fast (along with /O2 /GS-) or could this create problems with propagation of the NaNs that can arise in OSG? Would trying to build with Intel C++ likely to give significantly better performance? This is probably a question of whether OSG would benefit from its better auto-vectorization. If I stick with the VC++ 2015 OSG build I should be OK linking my application built with Intel C++ 2016 to it since they seem to be binary compatible, right? Since I'll need to build future OSG releases I am willing to host the Windows OSG (starting with 3.4.0) binary packages on our company website if someone on the OSG team wants to add a link to it on the Stable Releases page. Just let me know who best to contact. Thank you! Cheers, Stuart[/list] -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=66848#66848 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Fedora 18 with nVidia driver: OSG crashes session
Thanks for all the input. The "Files" section with those 2 lines already appears in /etc/X11/xorg.conf.d/00-nvidia.conf but for some reason isn't getting picked up in F18. I am not sure there is a benefit to copying that to /usr/share/X11/xorg.conf.d/ as well. I am no expert on how the nvidia drivers use the xorg.conf system but since it is obsolete on Fedora it is a likely source of future grief, unfortunately. Not the place to debate distros but I can't agree with Fedora 18 being a "lemon" although I didn't use the new installer that is attracting complaints. Each Fedora release has problems initially that require these sorts of work-arounds but that is the nature of the beast. It is still a great development platform when you need the latest tools, although my Kubuntu 12.10 system is almost as up to date (except for kernels of course) and was a lot easier to set up. YMMV. Stuart -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=52337#52337 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Fedora 18 with nVidia driver: OSG crashes session
Hi, To clarify, problem is already solved with the fix to xorg.conf I posted. glxinfo and glxgears were not running correctly and now they are. Yes, I am running nvidia drivers properly and all was well under F17 as I stated. This is a bug in F18 that should get fixed eventually. Thanks all, Stuart -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=52323#52323 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Fedora 18 with nVidia driver: OSG crashes session
Hi Robert, You were right: the problem was broader than OSG. The fix was to modify /etc/X11/xorg.conf so that these 2 lines were in the "Files" section: Code: Section "Files" ModulePath "/usr/lib64/nvidia/xorg" ModulePath "/usr/lib64/xorg/modules" EndSection This comes from http://forums.fedoraforum.org/showthread.php?p=1626150 I hope this helps some other F18 users (until this bug is fixed). Cheers, Stuart -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=52308#52308 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Fedora 18 with nVidia driver: OSG crashes session
Hi Robert, No luck: Both osgviewer and my (debug build) app bring down the session even running under gdb. Running my app in its non-GUI mode that brings up a stand-alone OSG window doesn't kill the session. Instead I get: Code: Error: Not able to create requested visual. GraphicsWindow has not been created successfully. Error: Not able to create requested visual. GraphicsWindow has not been created successfully. Viewer::realize() - failed to set up any windows I don't know if that is helpful. We probably need to wait for someone else to chime in on whether OSG on F18+nVidia is working for them. BTW the current nvidia driver is 304.64-2.fc18. I think later drivers may be available in an rpmfusion testing repository in case we want to try that route. Cheers, Stuart[/code] -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=52292#52292 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Fedora 18 with nVidia driver: OSG crashes session
Hi, I recently upgraded a system from Fedora 17 to 18 (64-bit KDE spin). I am using the rpmfusion nvidia drivers and the upgrade (using the new fedup) seems to have gone well. Problem is, now my OSG applications as well as osgviewer crash my session instantly and send me back to the login screen! I didn't have any problem on Fedora 17. I did all the normal post-upgrade cleanups (distro sync, etc.) and all the OSG packages seem to be properly upgraded to the latest 3.0.1.1-3.fc18 versions. There is clearly something seriously wrong here. Any ideas? I'm happy to help debug this further. Thanks, Stuart -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=52267#52267 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Fedora 16 + nouveau + OSG 3.0.1 => assertion failure
Hi, Just updated to Fedora 16 running the nouveau video driver and now my app using OSG and osgviewer give this on exit: Inconsistency detected by ld.so: dl-close.c: 759: _dl_close: Assertion `map->l_init_called' failed! Anyone else seeing/seen this? Otherwise, I'm happy to see that my app built with 2.8.4 seems to run mostly fine without changes under 3.0.1. I looked for a porting guide but didn't find one. If anyone has pointers on needed or suggested changes for 3.0.1 I'd appreciate it. Thank you! Cheers, Stuart -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43783#43783 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org