[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#844357: fracplanet FTPFS on mips*: libQtOpenGL.so: undefined reference to `glLoadMatrixd'

Control: reassign -1 binutils 2.25-5
Control: severity -1 important
Control: affects -1 src:fracplanet
Control: retitle -1 binutils: mips* mesa libGL.so.1 contains an invalid symbol table

Hi,

On 14/11/16 19:08, Adrian Bunk wrote:
> Package: fracplanet
> Version: 0.4.0-5
> Severity: serious
> 
> https://buildd.debian.org/status/package.php?p=fracplanet&suite=sid
> 
> g++ -g -O2 -fdebug-prefix-map=/«PKGBUILDDIR»=. -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro -Wl,-O1 -o fracplanet obj/common.o obj/control.o obj/control_about.o obj/control_render.o obj/control_save.o obj/control_terrain.o obj/dialog_documentation.o obj/fracplanet.o obj/fracplanet_main.o obj/geometry.o obj/image.o obj/license.o obj/matrix33.o obj/matrix34.o obj/noise.o obj/parameters_cloud.o obj/parameters_noise.o obj/parameters_object.o obj/parameters_render.o obj/parameters_save.o obj/parameters_terrain.o obj/progress.o obj/random.o obj/rgb.o obj/scan.o obj/spinbox.o obj/triangle.o obj/triangle_edge.o obj/triangle_mesh.o obj/triangle_mesh_cloud.o obj/triangle_mesh_terrain.o obj/triangle_mesh_viewer.o obj/triangle_mesh_viewer_display.o obj/vertex.o obj/xyz.o obj/moc_control_about.o obj/moc_control_render.o obj/moc_control_save.o obj/moc_control_terrain.o obj/moc_dialog_documentation.o obj/moc_fracplanet_main.o obj/moc_triangle_mesh_viewer.o obj/moc_triang
>  le_mesh_viewer_display.o    -L/usr/lib/mips-linux-gnu -L/usr/X11R6/lib -lboost_program_options -lGLU -lQtOpenGL -lQtGui -lQtCore -lGL -lpthread 
> /usr/lib/mips-linux-gnu/libQtOpenGL.so: undefined reference to `glLoadMatrixd'
> 
> 
> Michael Biebl mentioned #844227 on IRC, are these bugs coincidence,
> or is there something that broke/changed in Mesa on mips* recently?

Looking at this a bit closer, it appears to be a longstanding binutils
bug which was recently made worse due to a change in counting local
symbols.

Dumping the dynamic symbol table of libGL.so.1 on mipsel shows the
first (long standing) bug:

$ readelf --syms libGL.so.1 | head -n15
Symbol table '.dynsym' contains 1559 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND
     1: 00000000000163c0     0 SECTION LOCAL  DEFAULT   10
     2: 00000000000902a8     0 SECTION LOCAL  DEFAULT   16
     3: 0000000000072640    52 FUNC    GLOBAL DEFAULT   11 glCheckFramebufferStatusE
     4: 000000000006c470    52 FUNC    GLOBAL DEFAULT   11 glConvolutionFilter1D
     5: 0000000000072198    28 FUNC    GLOBAL DEFAULT   11 glVertexAttrib3fvARB
     6: 000000000006b730    52 FUNC    GLOBAL DEFAULT   11 glLoadMatrixd
     7: 00000000000943d0     0 NOTYPE  LOCAL  DEFAULT   24 _fbss
     8: 000000000006c6a0    52 FUNC    GLOBAL DEFAULT   11 glGetConvolutionParameter
     9: 0000000000069730    52 FUNC    GLOBAL DEFAULT   11 glVertex4i
    10: 000000000006ebe0    52 FUNC    GLOBAL DEFAULT   11 glGetBufferPointervARB
    11: 000000000006e3d8    28 FUNC    GLOBAL DEFAULT   11 glWindowPos2f

Here the _fbss symbol is LOCAL which is prohibited by the ELF standard
which requires all LOCAL symbols to precede GLOBAL symbols. This bug is
definitely present in jessie's binutils, because jessie's libGL also
has a symbol table similar to this. Wheezy's mesa doesn't have this bug
but I don't know if binutils definitely doesn't have it in wheezy.

Ordinarily this wasn't much of an issue since glibc and ld would just
skip LOCAL symbols when processing the symbol tables. However somewhere
between binutils 2.27-9 and 2.27.51.20161108-1 the behavior for
calculating the 'st_info' field for the .dynsym section header changed.
Recompiling mesa with both versions of binutils gives identical libGL
binaries except for this difference in the section header:

diffoscope output (- 2.27-9, + 2.27.51.20161108-1):
│ -  [ 5] .dynsym           DYNSYM          0000000000002e40 002e40 009228 18   A  6   3  8
│ +  [ 5] .dynsym           DYNSYM          0000000000002e40 002e40 009228 18   A  6   9  8

Here 3 = the index of the first non-global symbol, and 9 = the total
number of local symbols. These values should of course be equal if the
rules about symbol ordering were followed. ld uses the value of the
'st_info' field to skip LOCAL symbols when linking, which explains why
only the 5 symbols from 3-8 in the above symbol table cause link errors.

I'm still investigating, but getting a reduced testcase is quite tricky
and recompiling mesa on mips takes about an hour.

Thanks,
James

Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: