[osg-users] freetype build support on Windows

[Stuart Mentzer]

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-...@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[Robert Osfield]

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.

[Robert Osfield]

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.

[Stuart Mentzer]

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

[Robert Osfield]

Hi Stuart,

On 2 June 2016 at 02:08, Stuart Mentzer <Stuart_...@objexx.com> wrote:
> 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.

Could you please try a build with the latest that I've checked in and
see what happens.

Robert.

[Stuart Mentzer]

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

[Robert Osfield]

Hi Stuart,

The PNG link in freetype is something we can't hardwire into the OSG's
freetype plugin as it will break the build for those who use freetype
without PNG and don't have png available.

Could you check the CMake FindFreetype.cmake to see if it has any var
for additional libraries that are required, I'd hope that something
like this will be picked up automatically so we can use this rather
than jump through hoops to handle and edge case like using Freetype
with PNG.

On the warnings front, please post them for discussion. I currently
don't see any warnings when building under Windows, but I have VS2013
installed so this might be the difference.

In general I'd like to clean up warnings, but we have be careful as
fixing warnings can introduce bugs as well as fix bugs. In most cases
fixing warnings doesn't fix actual bugs, so any risk of introducing
bugs has to be warranted and double checked to avoid this risk. And
yes on a number of occasions bugs have been introduced by warning
fixes, we have been burnt even when taking care.

In cases where the compiler is just generating warnings that are not
helpful and are too intrusive to fix I feel can be warranted to simply
disable the warning.

Robert.

[Stuart Mentzer]

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

[Stuart Mentzer]

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

[Robert Osfield]

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

[Stuart Mentzer]

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

[Robert Osfield]

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.

[Stuart Mentzer]

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

[Robert Osfield]

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.

[Carl-Gustaf Kung]

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

[Stuart Mentzer]

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:

[Stuart Mentzer]

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

[Stuart Mentzer]

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

[Robert Osfield]

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.

[Stuart Mentzer]

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

[Robert Osfield]

Hi Stuart,

On 8 June 2016 at 15:54, Stuart Mentzer <Stuart_...@objexx.com> 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.

[Stuart Mentzer]

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

[Robert Osfield]

Hi Stuart,

On 8 June 2016 at 16:11, Stuart Mentzer <Stuart_...@objexx.com> 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.

[Stuart Mentzer]

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

[Stuart Mentzer]

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

[Robert Osfield]

Hi Stuart,

On 9 June 2016 at 12:39, Stuart Mentzer <Stuart_...@objexx.com> 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.

[Stuart Mentzer]

Good points, Robert. I'm not the one to do this fancier CMake setup.

Stuart