Bug 233491 - graphics/osgearth: update to 2.10
Summary: graphics/osgearth: update to 2.10
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Thomas Zander
Keywords: needs-qa, patch
Depends on:
Reported: 2018-11-25 07:24 UTC by Loïc Bartoletti
Modified: 2018-12-09 07:56 UTC (History)
2 users (show)

See Also:

osgearth 2.10 (12.51 KB, patch)
2018-11-25 07:24 UTC, Loïc Bartoletti
lbartoletti: maintainer-approval+
Details | Diff
Patch including fix for i386 build (13.80 KB, patch)
2018-12-01 17:34 UTC, Thomas Zander
riggs: maintainer-approval? (lbartoletti)
Details | Diff
osgearth with files (2.01 KB, patch)
2018-12-01 17:37 UTC, Loïc Bartoletti
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Loïc Bartoletti freebsd_committer 2018-11-25 07:24:49 UTC
Created attachment 199533 [details]
osgearth 2.10


    REX terrain engine promoted to default. Old MP engine is now in legacy support mode.
    Removed the osgEarthQt nodekit from the SDK, along with all Qt examples
    Cleanup of the internal serialization architecture (i.e. osgEarth::Config)
    Compatibility with OSG 3.6.x release/branch
    GL3 and GLCORE profile support
    VirtualProgram performance improvements
    New LineDrawable and PointDrawable classes for cross-GL-profile support
    Better progress/cancelation handling throughout the SDK, including feature subsystem
    Prototype support for ECI reference frames
    Support for “new” osgText implementation in VirtualProgram framework
    New ClusterNode utility class for clustering proximite objects
    Removed deprecations: MaskNode, Profiler, StateSetLOD, TileKeyDataStore, WrapperLayer, MarkerResource, MarkerSymbol, StencilVolumeNode, TritonNode, AnnotationEvents, PolyhedralLineOfSight, some CullingUtils objects

Ports change:
Remove useless OSGVERSION variable
OSGEARTH wants linux memalign and not posix_memalign... So I include FreeBSD with APPLE to define malloc as a memalign......
Comment 1 Thomas Zander freebsd_committer 2018-12-01 17:32:33 UTC
This does not build on i386, patch proposal coming up ...
Comment 2 Thomas Zander freebsd_committer 2018-12-01 17:34:18 UTC
Created attachment 199716 [details]
Patch including fix for i386 build
Comment 3 Loïc Bartoletti freebsd_committer 2018-12-01 17:37:27 UTC
Created attachment 199717 [details]
osgearth with files

Sorry I forgot to add new files patch before made svn diff... my bad
Comment 4 Thomas Zander freebsd_committer 2018-12-01 17:38:26 UTC
(In reply to Thomas Zander from comment #2)

The problem is that the build system blindly assumes that all x86 processors come with SSE. This is only applicable to amd64 systems where SSE2 is part of the minimal specification.
For IA32 this is not the case, and there are processors out there which do not support SSE (and we do have users using those CPUs). Hence, the default build for i386 must deactivate SSE, see extra-patch in attachment 199716 [details].
Comment 5 Thomas Zander freebsd_committer 2018-12-01 18:04:18 UTC
(In reply to lbartoletti from comment #3)

No, the files you sent were fine. They just did not deal with the ia32 SSE problem. Can you check attachment 199716 [details] and let me know whether I can commit this or if something is missing?
Comment 6 Thomas Zander freebsd_committer 2018-12-07 09:42:03 UTC
Comment 7 Loïc Bartoletti freebsd_committer 2018-12-08 09:42:01 UTC
Thanks Thomas@

It's ok for me.
Comment 8 commit-hook freebsd_committer 2018-12-09 07:40:15 UTC
A commit references this bug:

Author: riggs
Date: Sun Dec  9 07:39:31 UTC 2018
New revision: 487028
URL: https://svnweb.freebsd.org/changeset/ports/487028

  Update to upstream version 2.10

  - Update to upstream version 2.10
  - Disable the unconditional dependency on SSE-optimized routines
    on i386, as it (1) results in build failures and (2) there are
    non-SSE-capable i386 CPUs in use in the FreeBSD community, thus
    the default package cannot depend on it.

  PR:		233491
  Submitted by:	lbartoletti@tuxfamily.org (maintainer)
  Reviewed by:	riggs

Comment 9 Thomas Zander freebsd_committer 2018-12-09 07:56:56 UTC