#456: Undefined references when building grass 6.4 rc2
-----------------------+----------------------------------------------------
Reporter: fundawang | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major | Milestone: 6.4.0
Component: default | Version: 6.4.0 RCs
Keywords: | Platform: Linux
Cpu: x86-64 |
-----------------------+----------------------------------------------------
When building grass 6.4 rc2 with LDFLAGS="-Wl,--no-undefined", it
generates a lot of undefined references.
Please check following patch: http://svn.mandriva.com/cgi-
bin/viewvc.cgi/packages/cooker/grass/current/SOURCES/grass-6.4.0-fix-
linkage.patch
#456: Undefined references when building grass 6.4 rc2
------------------------+---------------------------------------------------
Reporter: fundawang | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major | Milestone: 6.4.0
Component: default | Version: 6.4.0 RCs
Resolution: | Keywords:
Platform: Linux | Cpu: x86-64
------------------------+---------------------------------------------------
Comment (by neteler):
Please try attached patch, it correct the missing references (we use
variables for the references, not the hardcoded names). Fixed in 6.4.0svn,
6.4.svn. Work in progress for GRASS 7.
EXTRA_LIBS should only include the libraries which are used directly by
the library or module being built. Indirect dependencies should be handled
by the *LIB variables in Grass.make.
I intend to revert r35550, but first I'll attempt to determine what the
problem actually is and whether some other fix is necessary.
More generally, it would have been preferable for the reporter to have
attached the error messages (or at least a representative sample of them),
rather than attaching a patch and expecting it to be applied without any
understanding of the problem (the fact that it actually happened here
indicates a defect in the development process).
On Fri, Jan 23, 2009 at 1:21 PM, GRASS GIS <trac@osgeo.org> wrote:
> #456: Undefined references when building grass 6.4 rc2
>Ticket URL: <http://trac.osgeo.org/grass/ticket/456>
...
> Fixed also in GRASS 7.
/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/lib/libgrass_cairodriver.so)
OBJ.x86_64-unknown-linux-gnu/Text.o: In function `fc_init':
/home/neteler/grass70/lib/cairodriver/Text.c:180: undefined reference to `FcInit'
Apparently CAIRO_HAS_FT_FONT isn't set as missing from include/config.h
if I understand the problem correctly.
It isn't supposed to be set in <grass/config.h>, but in
<cairo-features.h>
This particular case isn't bogus, as cairodriver/Text.c uses
FontConfig directly, so it should be listed in the Makefile.
Unfortunately, there aren't any configure checks for it (and thus no
$(FCLIB) or similar that we can use); we just assume that if
CAIRO_HAS_FT_FONT is defined, then linking against cairo will pull in
FontConfig automatically.
I have opened ticket #459 for this specific issue.
Replying to [comment:6 glynn]:
> More generally, it would have been preferable for the reporter to have
attached the error messages (or at least a representative sample of them),
All are looking like this:
{{{
gcc -shared -o /home/neteler/grass64/dist.x86_64-unknown-linux-
gnu/lib/libgrass_driver.6.5.svn.so -L/home/neteler/grass64/dist.x86_64-
unknown-linux-gnu/lib -Wl,--no-undefined -Wl,--export-dynamic
-L/usr/lib64 -Wl,-rpath-link,/home/neteler/grass64/dist.x86_64-unknown-
linux-gnu/lib OBJ.x86_64-unknown-linux-gnu/Bitmap.o OBJ.x86_64-unknown-
linux-gnu/Box.o OBJ.x86_64-unknown-linux-gnu/Client.o OBJ.x86_64-unknown-
linux-gnu/Color.o OBJ.x86_64-unknown-linux-gnu/Cont.o OBJ.x86_64-unknown-
linux-gnu/Draw.o OBJ.x86_64-unknown-linux-gnu/Erase.o OBJ.x86_64-unknown-
linux-gnu/Font.o OBJ.x86_64-unknown-linux-gnu/Get_location.o OBJ.x86_64-
unknown-linux-gnu/Get_t_box.o OBJ.x86_64-unknown-linux-gnu/Graph.o OBJ.
x86_64-unknown-linux-gnu/Line_width.o OBJ.x86_64-unknown-linux-gnu/Move.o
OBJ.x86_64-unknown-linux-gnu/Panel.o OBJ.x86_64-unknown-linux-
gnu/Polydots.o OBJ.x86_64-unknown-linux-gnu/Polyline.o OBJ.x86_64-unknown-
linux-gnu/Polygon.o OBJ.x86_64-unknown-linux-gnu/Raster.o OBJ.x86_64-
unknown-linux-gnu/Respond.o OBJ.x86_64-unknown-linux-gnu/Returns.o OBJ.
x86_64-unknown-linux-gnu/Set_window.o OBJ.x86_64-unknown-linux-gnu/Text.o
OBJ.x86_64-unknown-linux-gnu/Text_size.o OBJ.x86_64-unknown-linux-
gnu/Work.o OBJ.x86_64-unknown-linux-gnu/font2.o OBJ.x86_64-unknown-linux-
gnu/font_freetype.o OBJ.x86_64-unknown-linux-gnu/init.o OBJ.x86_64-
unknown-linux-gnu/pad.o OBJ.x86_64-unknown-linux-gnu/parse_ftcap.o OBJ.
x86_64-unknown-linux-gnu/text2.o OBJ.x86_64-unknown-linux-gnu/text3.o OBJ.
x86_64-unknown-linux-gnu/main.o OBJ.x86_64-unknown-linux-gnu/command.o
OBJ.x86_64-unknown-linux-gnu/connect_sock.o -lgrass_gis -lgrass_datetime
-lz -lfreetype && \
(cd /home/neteler/grass64/dist.x86_64-unknown-linux-gnu/lib; ln -f
-s libgrass_driver.6.5.svn.so /home/neteler/grass64/dist.x86_64-unknown-
linux-gnu/lib/libgrass_driver.so)
OBJ.x86_64-unknown-linux-gnu/Polygon.o: In function `line':
/home/neteler/grass64/lib/driver/Polygon.c:54: undefined reference to
`floor'
OBJ.x86_64-unknown-linux-gnu/text2.o: In function `soft_text':
/home/neteler/grass64/lib/driver/text2.c:143: undefined reference to `sin'
/home/neteler/grass64/lib/driver/text2.c:144: undefined reference to `cos'
OBJ.x86_64-unknown-linux-gnu/text2.o: In function `onechar':
/home/neteler/grass64/lib/driver/text2.c:160: undefined reference to `sin'
/home/neteler/grass64/lib/driver/text2.c:161: undefined reference to `cos'
OBJ.x86_64-unknown-linux-gnu/text3.o: In function `set_matrix':
/home/neteler/grass64/lib/driver/text3.c:130: undefined reference to `cos'
/home/neteler/grass64/lib/driver/text3.c:131: undefined reference to `sin'
/home/neteler/grass64/lib/driver/text3.c:132: undefined reference to `sin'
/home/neteler/grass64/lib/driver/text3.c:133: undefined reference to `cos'
collect2: ld returned 1 exit status
make: *** [/home/neteler/grass64/dist.x86_64-unknown-linux-
gnu/lib/libgrass_driver.6.5.svn.so] Error 1
[neteler@host550 driver]$
}}}
The patch indicates the list of affected directories. Adding $(MATHLIB)
resolves it (maybe "resolves").
Replying to [comment:6 glynn]:
> This error, and its "fix", are bogus.
My mistake; the cairodriver change (the one which I tested) is bogus, but
the rest are legitimate (i.e. the library uses functions from the math
library directly).
However, I think that it's probably better to just add $(MATHLIB) to the
linking command in Shlib.make. Compile.make already do this for
executables (which is why it has never caused problems before), but not
for shared libraries.
Replying to [comment:10 glynn]:
> My mistake; the cairodriver change (the one which I tested) is bogus,
but the rest are legitimate (i.e. the library uses functions from the math
library directly).
> > My mistake; the cairodriver change (the one which I tested) is bogus,
but the rest are legitimate (i.e. the library uses functions from the math
library directly).
>
> How to deal with the cairodriver change in 6.4.x?
For whatever reason, the 6.4 version of the change (r35549) didn't touch
lib/cairodriver/Makefile, so no change is required.
I've found a new underlinking problem with cairo: http://svn.mandriva.com/cgi-
bin/viewvc.cgi/packages/cooker/grass/current/SOURCES/grass-6.4.0-linkage.patch