Re: C++ transition stumbling blocks?
On Tue, Jan 21, 2003 at 11:25:43PM -0500, Branden Robinson wrote:
> ...and now it's in queue/new on auric. (Needs overrides for the new
> Mesa GL/GLU split packages.)
I was going to make a proposal regarding this (how to handle the libgl1
virtual package), but I wanted to think it over...
Situation is this:
* All the libGL implementations that we ship are C libraries
* Some of the libGLU implementations are libraries with C
interfaces, but implemented in C++
* The libgl1 package provides two libraries: libGL and libGLU
* The mesa source package produces _three_ binary packages that
provide libGL, all of them use the same libGLU
* Some time ago I splitted libGLU off the mesa packages because it
really makes more sense so. All the binary packages depend on the
new libglu1 package in order to satisfy the virtual package
requirements. The reason for this is that in the future there are
going to be _more_ mesa packages (at least one more).
* I would like to make all these libGL packages parallel installable;
splitting libGLU to its own package makes things simpler. I'd
very much like to have the posibility to switch over to the
software rasterizer without much fuss.
* The NVIDIA libGL packages don't provide libGLU because NVIDIA
doesn't provide libGLU (which is ok). As a consequence, the
NVIDIA libGL packages play silly games with diversions -- in order
to satisfy the requirements of the libgl1 package. With a
separate libGLU package the NVIDIA packages can depend on this and
provide libgl1 like all the other libGL packages which in turn
means I can stop special-casing it.
* For some reason the libglu1 package doesn't depend on
libstdc++whatever; I have to take a look at this. With the old
package compiled with g++ 2.95.x this is ok, the library doesn't
have unresolved symbols which can be satisfied by
libstdc++whatever. With the new package (libglu1c102) the library
_does_ have some C++-related unresolved symbols:
$ readelf -s libGLU.so.1.3.500 | grep UND | grep -v 'UND gl' | grep -v GLIBC
0: 00000000 0 NOTYPE LOCAL DEFAULT UND
54: 00000000 0 NOTYPE GLOBAL DEFAULT UND _Znaj
58: 00000000 0 NOTYPE GLOBAL DEFAULT UND sqrt
216: 00000000 0 NOTYPE GLOBAL DEFAULT UND ceil
234: 00000000 0 NOTYPE GLOBAL DEFAULT UND floor
459: 00000000 0 NOTYPE GLOBAL DEFAULT UND _ZTVN10__cxxabiv120__si_c
469: 00000000 0 NOTYPE GLOBAL DEFAULT UND _ZdlPv
560: 00000000 0 NOTYPE GLOBAL DEFAULT UND __gxx_personality_v0
641: 00000000 0 NOTYPE GLOBAL DEFAULT UND _Unwind_Resume
715: 00000000 0 NOTYPE GLOBAL DEFAULT UND __cxa_pure_virtual
857: 00000000 0 NOTYPE GLOBAL DEFAULT UND _ZTVN10__cxxabiv117__clas
922: 00000000 0 NOTYPE GLOBAL DEFAULT UND _ZdaPv
1048: 00000000 0 NOTYPE GLOBAL DEFAULT UND _ZTVN10__cxxabiv121__vmi_
1207: 00000000 0 NOTYPE GLOBAL DEFAULT UND _Znwj
1350: 00000000 0 NOTYPE WEAK DEFAULT UND _Jv_RegisterClasses
1410: 00000000 0 NOTYPE WEAK DEFAULT UND __gmon_start__
but:
0x00000001 (NEEDED) Shared library: [libGL.so.1]
0x00000001 (NEEDED) Shared library: [libc.so.6]
libm.so.6 is missing obviously (I'll fix this) and the weird
looking symbols are nothing but:
00000000 D *UND* 00000000 operator new[](unsigned)
00000000 D *UND* 00000000 vtable for __cxxabiv1::__si_class_type_info
00000000 D *UND* 00000000 operator delete(void*)
00000000 D *UND* 00000000 __gxx_personality_v0
00000000 D *UND* 00000000 _Unwind_Resume
00000000 D *UND* 00000000 __cxa_pure_virtual
00000000 D *UND* 00000000 vtable for __cxxabiv1::__class_type_info
00000000 D *UND* 00000000 operator delete[](void*)
00000000 D *UND* 00000000 vtable for __cxxabiv1::__vmi_class_type_info
00000000 D *UND* 00000000 operator new(unsigned)
00000000 w D *UND* 00000000 _Jv_RegisterClasses
00000000 w D *UND* 00000000 __gmon_start__
if I can get this out of the picture, we could just ignore the
whole transition bussiness _in_this_particular_case_ -- which I'd
very much like to (mostly because we'd be recompiling a lot of
stuff because of a little implementation detail). Any clues how
to accomplish that? (Or what the not-so-obvious names are in the
previous table are?)
Ah, yes, the library is being linked like this:
$ /bin/sh ../libtool --mode=link g++ -g -O2 -o libGLU.la -rpath /usr/local/lib -version-info 4:500:3 -L../src dummy.lo -lGL libnurbs/interface/libNIFac.la libnurbs/internals/libNInt.la libnurbs/nurbtess/libNTess.la libtess/libtess.la libutil/libutil.la
--
Marcelo
Reply to: