Undefined references when building grass 6.4 rc4

[fundawang]

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

[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.

Markus

[neteler]

Fix for missing libs in Makefiles

[neteler]

Fixed also in GRASS 7.

[fundawang]

gui/wxpython/nviz/Makefile

still missing -lstdc++

[neteler]

Can you please test attached patch (backport from GRASS 7)?

[neteler]

attempt to fix missing -lstdc++ in gui/wxpythonnviz/Makefile

[fundawang]

yes. please commit it.

[glynn]

This error, and its "fix", are bogus.

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).

[fundawang]

just export LDFLAGS="-Wl,--no-undefined" before running configure, you'll get all of the undefined references errors.

[neteler]

I used

MYCFLAGS="-g -Wall  -fno-common"
MYCXXFLAGS="-g -Wall"
MYLDFLAGS="-Wl,--no-undefined"
LDFLAGS="$MYLDFLAGS" CFLAGS="$MYCFLAGS" CXXFLAGS="$MYCXXFLAGS" ./configure ...

and could perfectly reproduce (and "fix" the problem).

[neteler]

Replying to 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").

[glynn]

Replying to 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.

[glynn]

Replying to glynn:

However, I think that it's probably better to just add $(MATHLIB) to the linking command in Shlib.make.

Done in r35565. This probably shouldn't be back-ported due to the divergence between 6.x and 7.0 build system.

[neteler]

Replying to 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).

How to deal with the cairodriver change in 6.4.x?

[glynn]

Replying to neteler:

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.

[neteler]

OK, then I'll close the ticket as fixed.

[fundawang]

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

[fundawang]

still valid for 6.4 rc4

[fundawang]

ping??

[hamish]

Replying to fundawang:

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

-EXTRA_LIBS=$(DRIVERLIB) $(GISLIB) $(CAIROLIB)
+EXTRA_LIBS=$(DRIVERLIB) $(GISLIB) $(CAIROLIB) $(XLIB)

Cairo is cross-platform, X11 is not. We need to find another solution.

Hamish

[glynn]

Replying to hamish:

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

Saying "I've found a problem" then not actually saying what the problem is doesn't help anyone.

-EXTRA_LIBS=$(DRIVERLIB) $(GISLIB) $(CAIROLIB)
+EXTRA_LIBS=$(DRIVERLIB) $(GISLIB) $(CAIROLIB) $(XLIB)

The above is bogus; $(CAIROLIB) should already contain all of the necessary linking switches. If it doesn't, configure.in should be modified to set CAIROLIB correctly.

[fundawang]

If configure.in is to be modified, you should detect cairo-xlib rather than cairo. It provides extra linking libs:

$ pkg-config --libs cairo-xlib -lcairo -lX11

[glynn]

Replying to fundawang:

If configure.in is to be modified, you should detect cairo-xlib rather than cairo. It provides extra linking libs:

$ pkg-config --libs cairo-xlib
-lcairo -lX11

But the cairo driver doesn't use the Xlib backend. It can optionally use the Xrender backend; currently, we do:

cairo="cairo cairo-ft"
if test -n "$USE_X11"; then
	cairo="$cairo cairo-xlib-xrender"
fi
...
CAIROINC=`pkg-config --cflags $cairo`

If you build --without-x11, the cairo driver should still be built, supporting all of the file-based backends (PNM, PNG, BMP, PDF, PS, SVG). This should require X libraries.

If you build --with-x11, pkg-config ... cairo-xlib-xrender should provide all of the necessary switches.

Ah, I see; 6.4 has the Xrender code in the cairo driver but doesn't have the corresponding tests in configure.in. Someone who cares about 6.4 needs to back-port them from 7.0.

[neteler]

Replying to glynn:

Ah, I see; 6.4 has the Xrender code in the cairo driver but doesn't have the corresponding tests in configure.in. Someone who cares about 6.4 needs to back-port them from 7.0.

If that means to make it identical to 7, please consider attached patch.

Markus

[neteler]

Glynn, can I submit the patch? I didn't fully understand your comment.

Markus

[neteler]

cairo tests update

[glynn]

Replying to neteler:

Glynn, can I submit the patch? I didn't fully understand your comment.

It looks okay, although I don't know if there are any issues related to the build system divergence between 6.x and 7.0.

Also, see #419.

[neteler]

Patch "grass64_configure_in.diff" (cairo tests updated) applied: 6.5 in r36962 and 6.4.0svn in r36963

Markus