After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 697712 - should use -lm to build the planner binary
should use -lm to build the planner binary
Status: RESOLVED FIXED
Product: planner
Classification: Other
Component: General
0.14.x
Other Linux
: Normal normal
: ---
Assigned To: planner-maint
planner-maint
Depends on:
Blocks:
 
 
Reported: 2013-04-10 13:18 UTC by Sebastien Bacher
Modified: 2017-04-19 16:32 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
that fixes the issue (460 bytes, patch)
2013-04-10 13:18 UTC, Sebastien Bacher
rejected Details | Review
Libplannerapp does mathematics (338 bytes, patch)
2015-01-06 22:23 UTC, Ahmed Baïzid
none Details | Review
Libplannerapp does mathematics (601 bytes, patch)
2015-01-17 17:12 UTC, Ahmed Baïzid
committed Details | Review

Description Sebastien Bacher 2013-04-10 13:18:35 UTC
Created attachment 241149 [details] [review]
that fixes the issue

Building 0.14.6 on Ubuntu fails with that error:

"  CCLD   planner
/usr/bin/ld: ./.libs/libplannerapp.a(planner-window.o): undefined reference to symbol 'floor@@GLIBC_2.0'
/usr/bin/ld: note: 'floor@@GLIBC_2.0' is defined in DSO /lib/i386-linux-gnu/libm.so.6 so try adding it to the linker command line
/lib/i386-linux-gnu/libm.so.6: could not read symbols: Invalid operation
collect2: error: ld returned 1 exit status"

Since src/planner-window.c uses floor() it should link with -lm
Comment 1 Ahmed Baïzid 2015-01-06 21:37:52 UTC
January 2015, on Debian, I've got:

  CCLD     planner
/usr/bin/ld: ./.libs/libplannerapp.a(eel-canvas-rect.o): undefined reference to symbol 'trunc@@GLIBC_2.2.5'
//lib/x86_64-linux-gnu/libm.so.6: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status

The attached patch really fixes the issue.
Comment 2 Alexandre Franke 2015-01-06 21:52:28 UTC
Comment on attachment 241149 [details] [review]
that fixes the issue

Sébastien, can you push that please?
Comment 3 Ahmed Baïzid 2015-01-06 22:23:18 UTC
Created attachment 293987 [details] [review]
Libplannerapp does mathematics
Comment 4 Ahmed Baïzid 2015-01-06 22:25:12 UTC
It is libplannerapp.a problem, not planner.
Comment 5 Alexandre Franke 2015-01-17 16:48:01 UTC
Thanks for submitting the patch, Ahmed. Can you use git format-patch or git bz to create it so that I have proper commit message and author when I push it to the repo please? See https://wiki.gnome.org/Git/WorkingWithPatches for tips on how to do that.
Comment 6 Ahmed Baïzid 2015-01-17 17:12:47 UTC
Created attachment 294744 [details] [review]
Libplannerapp does mathematics
Comment 7 Alexandre Franke 2015-01-17 17:20:17 UTC
Review of attachment 294744 [details] [review]:

Thanks. I'll push that soon. If you could do the same for all your patches, that would be appreciated.
Comment 8 Ahmed Baïzid 2015-01-18 05:18:57 UTC
Who is doing what?

src/eel-canvas-rect.c: ceil(), floor(), sqrt()
src/planner-format.c: floor(), pow()
src/planner-gantt-background.c: floor()
src/planner-gantt-chart.c: floor(), log(), pow()
src/planner-gantt-header.c: floor()
src/planner-gantt-print.c: ceil(), pow()
src/planner-gantt-row.c: floor(), sqrt()
src/planner-scale-utils.c: floor()
src/planner-usage-chart.c: floor(), log(), pow()
src/planner-usage-row.c: floor(), sqrt()
src/planner-window.c: floor()
Comment 9 Anton Eliasson 2016-09-07 13:50:10 UTC
The patch was never pushed, and is still needed to build on Ubuntu 16.04 x86-64.
Comment 10 Alexandre Franke 2016-09-07 14:08:51 UTC
We haven't made any release in the meantime and current master is broken in some ways. Currently development is a bit stalled because we don't have a successor to the deprecated libgnomecanvas. Thus pushing the patch to git wouldn't make much of a difference from an upstream point of view for now.
Comment 11 Anton Eliasson 2016-09-08 09:23:23 UTC
I disagree. IMHO:

Master should be kept compiling at all times. Nothing discourages possible casual contributors like a failing build. To me it gives the impression of a badly-maintained project. It also prevents you from being able to ask bug reporters "does this happen with the current master?". Master may not be stable, but with this patch is builds fine. So I would claim that it is important.