[GRASS-dev] New NVIZ compile error

neteler · October 16, 2008, 10:06am

Today I recompiled GRASS 6.4.svn from scratch and failed
to compile NVIZ:

[neteler@markus nviz]$ make
make -C src
make[1]: Entering directory `/home/neteler/grass64/visualization/nviz/src'
gcc -L/home/neteler/grass64/dist.x86_64-unknown-linux-gnu/lib
-Wl,--export-dynamic -L/usr/lib64
-Wl,-rpath-link,/home/neteler/grass64/dist.x86_64-unknown-linux-gnu/lib
-L/usr/lib64 -ltk -lm -ltcl -lm -lGLU -lGL -lSM -lICE -lX11
-lXmu -lXext -lm -o nvwish
OBJ.x86_64-unknown-linux-gnu/nvizAppInit.o
OBJ.x86_64-unknown-linux-gnu/change_view.o
OBJ.x86_64-unknown-linux-gnu/draw.o
OBJ.x86_64-unknown-linux-gnu/exag.o
OBJ.x86_64-unknown-linux-gnu/glwrappers.o
OBJ.x86_64-unknown-linux-gnu/init_commands.o
OBJ.x86_64-unknown-linux-gnu/lights.o
OBJ.x86_64-unknown-linux-gnu/map_obj.o
OBJ.x86_64-unknown-linux-gnu/misc.o
OBJ.x86_64-unknown-linux-gnu/nviz_init.o
OBJ.x86_64-unknown-linux-gnu/position.o
OBJ.x86_64-unknown-linux-gnu/quick_draw.o
OBJ.x86_64-unknown-linux-gnu/anim_support.o
OBJ.x86_64-unknown-linux-gnu/cutplane_obj.o
OBJ.x86_64-unknown-linux-gnu/script_support.o
OBJ.x86_64-unknown-linux-gnu/do_zoom.o
OBJ.x86_64-unknown-linux-gnu/label.o
OBJ.x86_64-unknown-linux-gnu/nvizMain.o
OBJ.x86_64-unknown-linux-gnu/togl.o
OBJ.x86_64-unknown-linux-gnu/togl_cb.o
OBJ.x86_64-unknown-linux-gnu/query_vect.o
OBJ.x86_64-unknown-linux-gnu/volume.o
OBJ.x86_64-unknown-linux-gnu/togl_flythrough.o
OBJ.x86_64-unknown-linux-gnu/pick_vect_commands.o
OBJ.x86_64-unknown-linux-gnu/site_attr_commands.o
OBJ.x86_64-unknown-linux-gnu/site_highlight_commands.o -lgrass_ogsf
-lgrass_bitmap -lgrass_linkm -lgrass_g3d -lgrass_gis -lgrass_datetime
-lz -lgrass_gis -lgrass_datetime -lz -lgrass_sites
-lgrass_datetime -lgrass_dbmibase -lgrass_gis -lgrass_datetime -lz
-lgrass_dbmiclient -lgrass_dbmibase -lgrass_gis -lgrass_datetime -lz
    -lgrass_gis -lgrass_datetime -lz -lgrass_gis -lgrass_datetime
-lz -lgrass_vect -lgrass_dbmibase -lgrass_gis -lgrass_datetime -lz
     -lgrass_dbmiclient -lgrass_dbmibase -lgrass_gis -lgrass_datetime
-lz -lgrass_gis -lgrass_datetime -lz -lgrass_dgl
-lgrass_dig2 -lgrass_gis -lgrass_datetime -lz -lgrass_rtree
-lgrass_gis -lgrass_datetime -lz -lgrass_linkm -lgrass_rtree
-lgrass_vect -lgrass_dbmibase -lgrass_gis -lgrass_datetime -lz
-lgrass_dbmiclient -lgrass_dbmibase -lgrass_gis -lgrass_datetime -lz
   -lgrass_gis -lgrass_datetime -lz -lgrass_dgl -lgrass_dig2
-lgrass_gis -lgrass_datetime -lz -lgrass_rtree -lgrass_gis
-lgrass_datetime -lz -lgrass_linkm -lgrass_rtree \
                -lgrass_bitmap -lgrass_linkm -lgrass_linkm
-lgrass_vect -lgrass_dbmibase -lgrass_gis -lgrass_datetime -lz
-lgrass_dbmiclient -lgrass_dbmibase -lgrass_gis -lgrass_datetime -lz
   -lgrass_gis -lgrass_datetime -lz -lgrass_dgl -lgrass_dig2
-lgrass_gis -lgrass_datetime -lz -lgrass_rtree -lgrass_gis
-lgrass_datetime -lz -lgrass_linkm -lgrass_rtree -lgrass_dig2
-lgrass_gis -lgrass_datetime -lz -lgrass_rtree -lgrass_dgl
-lgrass_rtree -lgrass_linkm -lgrass_dbmiclient -lgrass_dbmibase
-lgrass_gis -lgrass_datetime -lz -lgrass_gis -lgrass_datetime -lz
     -lgrass_dbmibase -lgrass_gis -lgrass_datetime -lz
-L/usr/local/lib -lgdal -lgrass_sites -lgrass_datetime
-lgrass_dbmibase -lgrass_gis -lgrass_datetime -lz
-lgrass_dbmiclient -lgrass_dbmibase -lgrass_gis -lgrass_datetime -lz
   -lgrass_gis -lgrass_datetime -lz -lgrass_gis -lgrass_datetime
-lz -lgrass_vect -lgrass_dbmibase -lgrass_gis -lgrass_datetime -lz
     -lgrass_dbmiclient -lgrass_dbmibase -lgrass_gis -lgrass_datetime
-lz -lgrass_gis -lgrass_datetime -lz -lgrass_dgl
-lgrass_dig2 -lgrass_gis -lgrass_datetime -lz -lgrass_rtree
-lgrass_gis -lgrass_datetime -lz -lgrass_linkm -lgrass_rtree
-lgrass_form -lgrass_dbmibase -lgrass_gis -lgrass_datetime -lz
-lgrass_dbmiclient -lgrass_dbmibase -lgrass_gis -lgrass_datetime -lz
   -lgrass_gis -lgrass_datetime -lz -lgrass_gis -lgrass_datetime
-lz -lgrass_dbmiclient -lgrass_dbmibase -lgrass_gis
-lgrass_datetime -lz -lgrass_gis -lgrass_datetime -lz
-lgrass_dbmibase -lgrass_gis -lgrass_datetime -lz \
                -lgrass_g3d -lgrass_gis -lgrass_datetime -lz
-lgrass_gis -lgrass_datetime -lz -lz \
                -lgrass_datetime -ltiff \
                -lm
/home/neteler/grass64/dist.x86_64-unknown-linux-gnu/lib/libgrass_ogsf.so:
undefined reference to `guess_format'
/home/neteler/grass64/dist.x86_64-unknown-linux-gnu/lib/libgrass_ogsf.so:
undefined reference to `avpicture_get_size'
/home/neteler/grass64/dist.x86_64-unknown-linux-gnu/lib/libgrass_ogsf.so:
undefined reference to `av_freep'
/home/neteler/grass64/dist.x86_64-unknown-linux-gnu/lib/libgrass_ogsf.so:
undefined reference to `av_destruct_packet_nofree'
/home/neteler/grass64/dist.x86_64-unknown-linux-gnu/lib/libgrass_ogsf.so:
undefined reference to `av_write_trailer'
/home/neteler/grass64/dist.x86_64-unknown-linux-gnu/lib/libgrass_ogsf.so:
undefined reference to `av_rescale_q'
/home/neteler/grass64/dist.x86_64-unknown-linux-gnu/lib/libgrass_ogsf.so:
undefined reference to `url_fclose'
/home/neteler/grass64/dist.x86_64-unknown-linux-gnu/lib/libgrass_ogsf.so:
undefined reference to `avcodec_close'
/home/neteler/grass64/dist.x86_64-unknown-linux-gnu/lib/libgrass_ogsf.so:
undefined reference to `avcodec_alloc_frame'
/home/neteler/grass64/dist.x86_64-unknown-linux-gnu/lib/libgrass_ogsf.so:
undefined reference to `avcodec_find_encoder'
/home/neteler/grass64/dist.x86_64-unknown-linux-gnu/lib/libgrass_ogsf.so:
undefined reference to `av_set_parameters'
/home/neteler/grass64/dist.x86_64-unknown-linux-gnu/lib/libgrass_ogsf.so:
undefined reference to `av_write_frame'
/home/neteler/grass64/dist.x86_64-unknown-linux-gnu/lib/libgrass_ogsf.so:
undefined reference to `av_free'
/home/neteler/grass64/dist.x86_64-unknown-linux-gnu/lib/libgrass_ogsf.so:
undefined reference to `avcodec_encode_video'
/home/neteler/grass64/dist.x86_64-unknown-linux-gnu/lib/libgrass_ogsf.so:
undefined reference to `url_fopen'
/home/neteler/grass64/dist.x86_64-unknown-linux-gnu/lib/libgrass_ogsf.so:
undefined reference to `av_write_header'
/home/neteler/grass64/dist.x86_64-unknown-linux-gnu/lib/libgrass_ogsf.so:
undefined reference to `av_register_all'
/home/neteler/grass64/dist.x86_64-unknown-linux-gnu/lib/libgrass_ogsf.so:
undefined reference to `avpicture_fill'
/home/neteler/grass64/dist.x86_64-unknown-linux-gnu/lib/libgrass_ogsf.so:
undefined reference to `avcodec_open'
/home/neteler/grass64/dist.x86_64-unknown-linux-gnu/lib/libgrass_ogsf.so:
undefined reference to `dump_format'
/home/neteler/grass64/dist.x86_64-unknown-linux-gnu/lib/libgrass_ogsf.so:
undefined reference to `av_new_stream'
/home/neteler/grass64/dist.x86_64-unknown-linux-gnu/lib/libgrass_ogsf.so:
undefined reference to `av_malloc'
/home/neteler/grass64/dist.x86_64-unknown-linux-gnu/lib/libgrass_ogsf.so:
undefined reference to `av_alloc_format_context'
collect2: ld returned 1 exit status
make[1]: *** [nvwish] Error 1
make[1]: Leaving directory `/home/neteler/grass64/visualization/nviz/src'
make: *** [default] Error 2

Could this be related to recent Mac changes? I didn't upgrade my Linux box..

Markus

William_Kyngesburye · October 16, 2008, 2:14pm

On Oct 16, 2008, at 5:06 AM, Markus Neteler wrote:

/home/neteler/grass64/dist.x86_64-unknown-linux-gnu/lib/libgrass_ogsf.so:
undefined reference to `guess_format'
/home/neteler/grass64/dist.x86_64-unknown-linux-gnu/lib/libgrass_ogsf.so:
undefined reference to `avpicture_get_size'
/home/neteler/grass64/dist.x86_64-unknown-linux-gnu/lib/libgrass_ogsf.so:

...

Could this be related to recent Mac changes? I didn't upgrade my Linux box..

No Mac changes directly in the TclTk Nviz. I did make a change yesterday in the ogsf makefile to only directly include X11 header and lib search paths if X11 opengl is used, to help avoid accidental inclusion (on OSX) of X11 copies of libraries. Shouldn't affect other systems, or nviz.

Have you always built with ffmpeg support? That's what all those symbols are from. Odd that the ffmpeg libraries aren't included in the nviz makefile.

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

"This is a question about the past, is it? ... How can I tell that the past isn't a fiction designed to account for the discrepancy between my immediate physical sensations and my state of mind?"

- The Ruler of the Universe

Glynn_Clements1 · October 16, 2008, 3:56pm

William Kyngesburye wrote:

> /home/neteler/grass64/dist.x86_64-unknown-linux-gnu/lib/
> libgrass_ogsf.so:
> undefined reference to `guess_format'
> /home/neteler/grass64/dist.x86_64-unknown-linux-gnu/lib/
> libgrass_ogsf.so:
> undefined reference to `avpicture_get_size'
> /home/neteler/grass64/dist.x86_64-unknown-linux-gnu/lib/
> libgrass_ogsf.so:
...
>
> Could this be related to recent Mac changes? I didn't upgrade my
> Linux box..

The above are all related to FFMPEG.

Have you always built with ffmpeg support? That's what all those
symbols are from. Odd that the ffmpeg libraries aren't included in
the nviz makefile.

Not really; NVIZ doesn't use FFMPEG. The OGSF library uses FFMPEG, and
lib/ogsf/Makefile has the correct flags. Or rather, it did prior to
r33887 (and still does in 7.0).

The problem is the use of ":=" in r33887. Whereas "=" assigns the RHS
literally (with any variable references left unexpanded), ":="
recursively expands any variable references in the RHS prior to
assignment.

At the point that the assignment occurs, none of the variables which
appear on the RHS have been defined (Lib.make isn't included until
later).

[Except for $(EXTRA_LIBS), but that evaluates to a bunch of other
variable references, none of which have been defined.]

The net result is that EXTRA_LIBS ends up empty. This doesn't cause
any problems when the OGSF library is built, but it will cause
problems when you try to link an executable (i.e. NVIZ) against it.

The code should have used either "=" or (preferably) "+=", e.g.:

  ifeq ($(OPENGL_X11),1)
  EXTRA_LIBS += $(XLIBPATH) $(OPENGLLIB) $(OPENGLULIB)
  else
  EXTRA_LIBS += $(OPENGLLIB) $(OPENGLULIB)
  endif

In general: don't use ":=" unless you have a particularly good reason
for doing so. If you do need to use ":=", you need to ensure that any
variables which are referenced (directly or indirectly) on the RHS
have already been defined.

Most of the time, "=" is the correct assignment operator. One of the
few valid reasons for using ":=" is if the RHS is an expensive
function call such as $(shell ...) or $(wildcard ...), where you want
to ensure that the function is only called once even if the variable
is referenced multiple times.

--
Glynn Clements <glynn@gclements.plus.com>

William_Kyngesburye · October 16, 2008, 4:23pm

On Oct 16, 2008, at 10:56 AM, Glynn Clements wrote:

The problem is the use of ":=" in r33887. Whereas "=" assigns the RHS
literally (with any variable references left unexpanded), ":="
recursively expands any variable references in the RHS prior to
assignment.

...

The code should have used either "=" or (preferably) "+=", e.g.:

  ifeq ($(OPENGL_X11),1)
  EXTRA_LIBS += $(XLIBPATH) $(OPENGLLIB) $(OPENGLULIB)
  else
  EXTRA_LIBS += $(OPENGLLIB) $(OPENGLULIB)
  endif

Thanks for the clarification. I was going from example from another makefile I was currently looking at (wxpython/vdigit), though I did notice that yet another used += (lib/nviz).

I just changed lib/ogsf/Makefile, and the wx nviz and vdigit makefiles to use +=.

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

"Oh, look, I seem to have fallen down a deep, dark hole. Now what does that remind me of? Ah, yes - life."

- Marvin

neteler · October 16, 2008, 4:32pm

On Thu, Oct 16, 2008 at 6:23 PM, William Kyngesburye
<woklist@kyngchaos.com> wrote:

On Oct 16, 2008, at 10:56 AM, Glynn Clements wrote:

The problem is the use of ":=" in r33887. Whereas "=" assigns the RHS
literally (with any variable references left unexpanded), ":="
recursively expands any variable references in the RHS prior to
assignment.

...

The code should have used either "=" or (preferably) "+=", e.g.:

       ifeq ($(OPENGL_X11),1)
       EXTRA_LIBS += $(XLIBPATH) $(OPENGLLIB) $(OPENGLULIB)
       else
       EXTRA_LIBS += $(OPENGLLIB) $(OPENGLULIB)
       endif

Thanks for the clarification. I was going from example from another
makefile I was currently looking at (wxpython/vdigit), though I did notice
that yet another used += (lib/nviz).

I just changed lib/ogsf/Makefile, and the wx nviz and vdigit makefiles to
use +=.

Thanks, now it compiles again.

Markus

Glynn_Clements1 · October 16, 2008, 5:32pm

William Kyngesburye wrote:

On Oct 16, 2008, at 10:56 AM, Glynn Clements wrote:

> The problem is the use of ":=" in r33887. Whereas "=" assigns the RHS
> literally (with any variable references left unexpanded), ":="
> recursively expands any variable references in the RHS prior to
> assignment.
...
> The code should have used either "=" or (preferably) "+=", e.g.:
>
> ifeq ($(OPENGL_X11),1)
> EXTRA_LIBS += $(XLIBPATH) $(OPENGLLIB) $(OPENGLULIB)
> else
> EXTRA_LIBS += $(OPENGLLIB) $(OPENGLULIB)
> endif

Thanks for the clarification. I was going from example from another
makefile I was currently looking at (wxpython/vdigit), though I did
notice that yet another used += (lib/nviz).

I just changed lib/ogsf/Makefile, and the wx nviz and vdigit makefiles
to use +=.

Right. In vdigit/Makefile, the lines:

SOURCES := $(wildcard *.cpp) $(LIB_NAME)_wrap.cpp
SHLIB_OBJS := $(patsubst %.cpp, $(OBJDIR)/%.o, $(SOURCES))

are examples of where ":=" makes sense, particularly the first one.

EXTRA_LIBS should use "+=", though.

In retrospect, "=" could be problematic for cases where the RHS
contains a reference to the LHS (I don't know how make handles this
case).

--
Glynn Clements <glynn@gclements.plus.com>