|Anonymous | Login||2017-11-20 12:20 EST|
|Main | My View | View Issues | Change Log | Roadmap | My Account|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001895||graphviz||Build/Install||public||2010-06-01 10:32||2012-01-19 14:17|
|Summary||0001895: sincos check doesn't use -lm|
sincos check in configure claims to verify if libm provides sincos, but
in fact it doesn't use -lm and with newer versions of GCC (4.3+) this
actually checks if GCC provides sincos, which is not the same.
On FreeBSD libm doesn't provide sincos, but configure decides that it
does if GCC 4.3+ is used for build and that causes link failures because
actual binaries are being linked with libm.
I don't think I understand. If configure finds a sincos in gcc libs, why is that incompatible with -lm ?
Anyway I have no way to test BSD builds. Could you generate a patch that works for you please?
I _think_ (far from sure) that if -lm is not explicitly specified then GCC uses
its "built-in" math functions, but if there is -lm, then it suppresses its code
and expects all functions to be provided in libm.so.
That's my assumption.
> Anyway I have no way to test BSD builds. Could you generate a patch
> > that works for you please?
I will try, but I have no auto-* skills :(
One less mystery - I also have my CFLAGS set to "-O2 ..." and apparently GCC 4.3+
is smarter than before, and it simply optimized away sincos(PI/2.0) call and
replaced results with constants. So the check was effective a NOOP.
Resetting CFLAGS to -O0 resulted in correct detection, -O1 was already too much of
I think that GCC-specific attribute could be used to force optimization level for
this test, something like "__attribute__((__optimize__(0)))".
But I am not sure if that would be a right thing to do.
In any case, I think that this check should use -lm to work correctly, otherwise
it would fail if sincos is not optimized out. It's a case of two bugs canceling
each other, at least on Linux :)
So, if I understand, it was mistakenly finding sincos() on BSD because the compiler was too clever.
I've tried to make the configure test defeat the optimizer. Now, if it doesn't find sincos() it should just use the regular sin(),cos().
I can't use gcc-specific flags because we don't always use gcc for graphviz builds.
Please see if tomorrow's snapshot works for you.
> On 06/01/2010 12:48 PM, Andriy Gapon wrote:
> > So, if I understand, it was mistakenly finding sincos() on BSD because
> > the compiler was too clever.
You outsmarted the compiler, the check works correctly in my environment now.
Thanks a lot!
However, please double-check that it doesn't mistakingly fail in Linux
environment now - I am saying because I don't see -lm in its compilation flags.
Snippet from config.log in FreeBSD environment:
configure:34899: checking if have working sincos()
configure:34942: gcc44 -o conftest -O2 -pipe -O2 -fno-strict-aliasing -pipe
-march=amdfam10 -Wstrict-prototypes -Wpointer-arith -Wall -ffast-math -I/usr
/local/include -I/usr/local/include/tk8.5 -I/usr/local/include/tcl8.5
-I/usr/local/include -L/usr/local/lib -L/usr/local/lib/python2.6 -L/usr/local/lib
conftest.c:142: warning: function declaration isn't a prototype
/var/tmp//ccaCGg1E.o: In function `main':
conftest.c:(.text+0x31): undefined reference to `sincos'
conftest.c:(.text+0x44): undefined reference to `sincos'
|Tags||No tags attached.|
|FIX-COMMENT||presumed fixed - no additional reports of problems on linux.|
|2011-04-28 04:03||user1||New Issue|
|2011-04-28 04:03||user1||Assigned To||=> user695|
|2012-01-19 14:17||ellson||FIX-COMMENT||=> presumed fixed - no additional reports of problems on linux.|
|2012-01-19 14:17||ellson||Status||acknowledged => resolved|
|2012-01-19 14:17||ellson||Resolution||open => fixed|
|MantisBT 1.2.5[^] Copyright © 2000 - 2011 MantisBT Group|