#440 closed defect (wontfix)
xmltester failures under MingW 32 bit
Reported by: | robe | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | GEOS Fund Me |
Component: | Default | Version: | main |
Severity: | Unassigned | Keywords: | mingw |
Cc: |
Description
strk,
Attached is the log file of my failures on geos 3.3.0 rc1 compilation of tar ball.
Attachments (2)
Change History (13)
by , 13 years ago
Attachment: | makecheckgeos_fails.log added |
---|
comment:1 by , 13 years ago
comment:3 by , 13 years ago
It'll be automatic if you're using automake and your compiler supports it. Check with:
grep AM_CXXFLAGS Makefile
comment:4 by , 13 years ago
Looks like it does
AM_CXXFLAGS = -DGEOS_INLINE -pedantic -Wall -ansi -Wno-long-long -ffloat-store
comment:5 by , 13 years ago
With geos 3.3.0rc2 i still get 4 failures. I'll attach my new log in case it's different.
by , 13 years ago
comment:6 by , 13 years ago
Could you also check:
grep CXXFLAGS Makefile
I want to make sure -O2 is used. Also, which compiler version ? Both failing tests are very sensible to numeric robustness issues...
comment:7 by , 13 years ago
strk output is:
AM_CXXFLAGS = -DGEOS_INLINE -pedantic -Wall -ansi -Wno-long-long -ffloat-store CXXFLAGS = -g -O2
comment:8 by , 13 years ago
Just for extra information:
I'm running: gcc version 3.4.5 (mingw-vista special r3
I'll try a newer one once I remember how I toggled back and forth between the 2 gccs before.
comment:9 by , 13 years ago
Milestone: | 3.3.0 → GEOS Future |
---|
unless someone commits to fix this there's no point in targetting a real milestone.
comment:10 by , 11 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
3.4.5 is pretty much dead. I think this is moot and doesn't affect my mingw64-w32 chain.
Failure for #350 is indeed the originally reported faiure. This is annoying. Are you sure you're building with -ffloat-store ? Could you retry that with r3338 or r3335 ? Or generally bisect to see if you got any success for it ?
As per the #398 failure it does look like a minor coordinate drift. We're checking for exact equality (pointwise) which is the reason for the failure. Note that also JTS checks for pointwise equality, which is the reason why I've tried to track as closely as possible JTS as per operations precision, getting back from long doubles to single doubles...