Skip to content

[osgearth] Adapt to the geos latest version#13332

Closed
JackBoosY wants to merge 1 commit intomicrosoft:masterfrom
JackBoosY:dev/jack/13292
Closed

[osgearth] Adapt to the geos latest version#13332
JackBoosY wants to merge 1 commit intomicrosoft:masterfrom
JackBoosY:dev/jack/13292

Conversation

@JackBoosY
Copy link
Contributor

Due to the update of geos to 3.8.1, osgearth cannot adapt to the changes of the new version(pelicanmapping/osgearth#1455).
Use the unofficial changes pelicanmapping/osgearth#1497 to fix the issue.

Will merge this issue after pelicanmapping/osgearth#1497 merged.

Fixes #13292.

@JackBoosY JackBoosY added category:port-bug The issue is with a library, which is something the port should already support info:internal depends:upstream-changes Waiting on a change to the upstream project labels Sep 3, 2020
coords->push_back( coords->front() );
}
+#if GEOS_VERSION_AT_LEAST(3,8)
+ geom::CoordinateSequence::Ptr seq = factory->create(coords);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems wrong.
geom::CoordinateSequence::Ptr is a unique_ptr which will be released as soon as the context goes out of scope.
You will be returning a freed memory by returning seq.get()
seq.release would probably work but there might be a memory leak

@ankurvdev
Copy link
Contributor

Due to the update of geos to 3.8.1, osgearth cannot adapt to the changes of the new version(gwaldron/osgearth#1455).
Use the unofficial changes gwaldron/osgearth#1497 to fix the issue.

Will merge this issue after gwaldron/osgearth#1497 merged.

Fixes #13292.

osgearth seems broken after the geos 3.8.1 update.
I'm curious as to how did the geos update sneak in (which breaks osgearth) without triggering a pipeline build failure in osgearth.
Shouldnt this have been caught by the pipeline build in the Pull-Request for the geos 3.8.1 update ?

@ankurvdev
Copy link
Contributor

Seems like the right fix has been merged into osgearth

pelicanmapping/osgearth@ef631e0

Can we perhaps abandon the Pull-Request and move over the port to the above commit ?

@ankurvdev
Copy link
Contributor

created a pull request with the right commit
#13385

@JackBoosY JackBoosY closed this Sep 7, 2020
@JackBoosY JackBoosY deleted the dev/jack/13292 branch September 7, 2020 07:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

category:port-bug The issue is with a library, which is something the port should already support depends:upstream-changes Waiting on a change to the upstream project

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[osgearth:x64-windows] build failure

3 participants