[GRASS-dev] nviz compilation problem

GRASS GIS GRASS GIS developer
1

I have compiled the CVS GRASS63 on a new 64bit computer with nvidia graphics card running
RedHat Enterprise Linux. Everything compiled successfully except for nviz that has some troubles with
shared GL libraries.
I have seen others with similar problems (I had it on another machine too ) mostly due to broken symlink,
but that does not seem to be the case here:

Errors in:
/local/home/helena/grassdev/grass6/lib/ogsf
/local/home/helena/grassdev/grass6/visualization/nviz

(cd /local/home/helena/grassdev/grass6/dist.x86_64-unknown-linux-gnu/lib; ln -f -s libgrass_ogsf.6.3.cvs.so /local/home/helena/grassdev/grass6/dist.x86_64-unknown-linux-gnu/lib/libgrass_ogsf.so)
/usr/bin/ld: /usr/X11R6/lib64/libGL.a(glapi.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
/usr/X11R6/lib64/libGL.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
make: *** [/local/home/helena/grassdev/grass6/dist.x86_64-unknown-linux-gnu/lib/libgrass_ogsf.6.3.cvs.so] Error 1

what to recompile with -fPIC? if that is really the problem?

thanks a lot for any hints,

Helena

2

Helena Mitasova wrote:

I have compiled the CVS GRASS63 on a new 64bit computer with nvidia
graphics card running
RedHat Enterprise Linux. Everything compiled successfully except for
nviz that has some troubles with
shared GL libraries.
I have seen others with similar problems (I had it on another machine
too ) mostly due to broken symlink,
but that does not seem to be the case here:

Errors in:
/local/home/helena/grassdev/grass6/lib/ogsf
/local/home/helena/grassdev/grass6/visualization/nviz

(cd /local/home/helena/grassdev/grass6/dist.x86_64-unknown-linux-gnu/lib; ln -f -s libgrass_ogsf.6.3.cvs.so /local/home/helena/grassdev/grass6/dist.x86_64-unknown-linux-gnu/lib/libgrass_ogsf.so)
/usr/bin/ld: /usr/X11R6/lib64/libGL.a(glapi.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
/usr/X11R6/lib64/libGL.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
make: *** [/local/home/helena/grassdev/grass6/dist.x86_64-unknown-linux-gnu/lib/libgrass_ogsf.6.3.cvs.so] Error 1

what to recompile with -fPIC?

libGL.a :frowning:

if that is really the problem?

The main problem is that you have a static libGL rather than a shared
libGL. The GRASS build system tends to assume that all external libraries
are shared libraries (unless building with --disable-shared, in which
case either will work).

You can probably work around it by removing $(OPENGLLIB) $(OPENGLULIB)
from the definition of EXTRA_LIBS in lib/ogsf/Makefile, and adding them
either to the definition of OGSFLIB in include/Make/Grass.make[.in] or to
the individual Makefiles (primarily, visualization/nviz/src/Makefile).

Actually, the NVIZ Makefile adds these explicitly, and r3.showdspf is no
longer compiled, so simply removing them from lib/ogsf/Makefile will
probably suffice.

Ideally, external shared libraries would be linked into the library while
external static libraries would be linked into each module which uses the
library. But I have no idea how to tell whether an external library is
shared or static; configure just checks whether adding "-l<library>"
works.

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

3

On Jun 27, 2007, at 12:53 AM, Glynn Clements wrote:

Helena Mitasova wrote:

I have compiled the CVS GRASS63 on a new 64bit computer with nvidia
graphics card running
RedHat Enterprise Linux. Everything compiled successfully except for
nviz that has some troubles with
shared GL libraries.
I have seen others with similar problems (I had it on another machine
too ) mostly due to broken symlink,
but that does not seem to be the case here:

Errors in:
/local/home/helena/grassdev/grass6/lib/ogsf
/local/home/helena/grassdev/grass6/visualization/nviz

(cd /local/home/helena/grassdev/grass6/dist.x86_64-unknown-linux-gnu/lib; ln -f -s libgrass_ogsf.6.3.cvs.so /local/home/helena/grassdev/grass6/dist.x86_64-unknown-linux-gnu/lib/libgrass_ogsf.so)
/usr/bin/ld: /usr/X11R6/lib64/libGL.a(glapi.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
/usr/X11R6/lib64/libGL.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
make: *** [/local/home/helena/grassdev/grass6/dist.x86_64-unknown-linux-gnu/lib/libgrass_ogsf.6.3.cvs.so] Error 1

what to recompile with -fPIC?

libGL.a :frowning:

if that is really the problem?

The main problem is that you have a static libGL rather than a shared
libGL. The GRASS build system tends to assume that all external libraries
are shared libraries (unless building with --disable-shared, in which
case either will work).

You can probably work around it by removing $(OPENGLLIB) $(OPENGLULIB)
from the definition of EXTRA_LIBS in lib/ogsf/Makefile, and adding them
either to the definition of OGSFLIB in include/Make/Grass.make[.in] or to
the individual Makefiles (primarily, visualization/nviz/src/Makefile).

Actually, the NVIZ Makefile adds these explicitly, and r3.showdspf is no
longer compiled, so simply removing them from lib/ogsf/Makefile will
probably suffice.

Glynn,

thank you for your help - removing $(OPENGLLIB) $(OPENGLULIB) from
the ogsf/Makefile solved the ogsf compilation problem.

The nviz compilation still gives a related error:

Errors in:
/local/home/helena/grassdev/grass6/visualization/nviz

/usr/X11R6/lib64/libGL.a(glxcmds.o)(.text+0x32c1): In function `glXGetMscRateOML':
: undefined reference to `XF86VidModeQueryVersion'
/usr/X11R6/lib64/libGL.a(glxcmds.o)(.text+0x32fd): In function `glXGetMscRateOML':
: undefined reference to `XF86VidModeGetModeLine'
collect2: ld returned 1 exit status
make[1]: *** [nvwish] Error 1
make[1]: Leaving directory `/local/home/helena/grassdev/grass6/visualization/nviz/src'
make: *** [nvwish] Error 2

thanks you

Helena

Ideally, external shared libraries would be linked into the library while
external static libraries would be linked into each module which uses the
library. But I have no idea how to tell whether an external library is
shared or static; configure just checks whether adding "-l<library>"
works.

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

4

Helena Mitasova wrote:

thank you for your help - removing $(OPENGLLIB) $(OPENGLULIB) from
the ogsf/Makefile solved the ogsf compilation problem.

The nviz compilation still gives a related error:

Errors in:
/local/home/helena/grassdev/grass6/visualization/nviz

/usr/X11R6/lib64/libGL.a(glxcmds.o)(.text+0x32c1): In function `glXGetMscRateOML':
: undefined reference to `XF86VidModeQueryVersion'

Ick. You should be able to work around this by manually adding
-lXxf86vm to the definition of OPENGLLIB in Platform.make (once
configure has generated it).

Unfortunately, it's hard for configure to detect this sort of thing
when using static libraries.

Linking against a shared library uses the entire library as a
monolithic entity, and will require any dependencies which the library
has.

OTOH, linking against a static library only uses the specific object
files which are actually required to satisfy any unresolved symbols,
and so only requires any dependencies of those specific object files.

The result is that a test program which uses a single function (e.g.
one generated by autoconf's AC_CHECK_LIB) will typically have fewer
dependencies than the real program (e.g. NVIZ).

E.g. a test program linked against -lGL will only require -lXxf86vm if
it references a function which is defined in glxcmds.o. Currently, the
test is for glBegin, which will certainly be in a different file (the
generic gl* functions and the X11-specific glX* functions are largely
separate), so the test doesn't need -lXxf86vm although NVIZ itself
does.

We could change the autoconf test to check for e.g. glXCreateContext,
which is more likely to require that file. But, ultimately, the only
solution for static libraries is to play "whack-a-mole", continually
adjusting the tests whenever ATI/nVidia change their OpenGL drivers.

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

5

Glynn,

thanks a lot for your help - I asked our sys admin to check the libGL and apparently
the symlinks were the problem again. Just for the record, in case somebody has a similar problem
this is what he says:

I took a closer look at things and noticed that there
were a few symlinks that pointed at nothing. Re-installing
the packages cleared that up -- and the files that appeared
to be missing were /usr/X11R6/lib64/libGL things.

after that everything compiled just fine and nviz runs great,

Helena

On Jun 28, 2007, at 7:09 AM, Glynn Clements wrote:

Helena Mitasova wrote:

thank you for your help - removing $(OPENGLLIB) $(OPENGLULIB) from
the ogsf/Makefile solved the ogsf compilation problem.

The nviz compilation still gives a related error:

Errors in:
/local/home/helena/grassdev/grass6/visualization/nviz

/usr/X11R6/lib64/libGL.a(glxcmds.o)(.text+0x32c1): In function `glXGetMscRateOML':
: undefined reference to `XF86VidModeQueryVersion'

Ick. You should be able to work around this by manually adding
-lXxf86vm to the definition of OPENGLLIB in Platform.make (once
configure has generated it).

Unfortunately, it's hard for configure to detect this sort of thing
when using static libraries.

Linking against a shared library uses the entire library as a
monolithic entity, and will require any dependencies which the library
has.

OTOH, linking against a static library only uses the specific object
files which are actually required to satisfy any unresolved symbols,
and so only requires any dependencies of those specific object files.

The result is that a test program which uses a single function (e.g.
one generated by autoconf's AC_CHECK_LIB) will typically have fewer
dependencies than the real program (e.g. NVIZ).

E.g. a test program linked against -lGL will only require -lXxf86vm if
it references a function which is defined in glxcmds.o. Currently, the
test is for glBegin, which will certainly be in a different file (the
generic gl* functions and the X11-specific glX* functions are largely
separate), so the test doesn't need -lXxf86vm although NVIZ itself
does.

We could change the autoconf test to check for e.g. glXCreateContext,
which is more likely to require that file. But, ultimately, the only
solution for static libraries is to play "whack-a-mole", continually
adjusting the tests whenever ATI/nVidia change their OpenGL drivers.

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