error: 'glGetBufferSubDataARB' was not declared in this scope

[darkoverlordofdata]

Debian Bullseye Linux 5.10.101-14960-gb2e5df468a73 aarch64

I'm compiling release 9.1, becuase some older games don't run on the current release, and I get tgis sysntax error:

make  all-recursive
make[1]: Entering directory '/home/darko/love-0.9.1'
Making all in src
make[2]: Entering directory '/home/darko/love-0.9.1/src'
make[3]: Entering directory '/home/darko/love-0.9.1/src'
depbase=`echo modules/graphics/opengl/VertexBuffer.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\
/bin/bash ../libtool  --tag=CXX   --mode=compile g++ -DHAVE_CONFIG_H -I. -I..  -I. -I./modules -I./libraries -I./libraries/enet/libenet/include  -D_FILE_OFFSET_BITS=64 -D_REENTRANT -I/usr/include/SDL2 -I/usr/include/luajit-2.1 -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/AL      -g -O2 -std=c++11 -MT modules/graphics/opengl/VertexBuffer.lo -MD -MP -MF $depbase.Tpo -c -o modules/graphics/opengl/VertexBuffer.lo modules/graphics/opengl/VertexBuffer.cpp &&\
mv -f $depbase.Tpo $depbase.Plo
libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I.. -I. -I./modules -I./libraries -I./libraries/enet/libenet/include -D_FILE_OFFSET_BITS=64 -D_REENTRANT -I/usr/include/SDL2 -I/usr/include/luajit-2.1 -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/AL -g -O2 -std=c++11 -MT modules/graphics/opengl/VertexBuffer.lo -MD -MP -MF modules/graphics/opengl/.deps/VertexBuffer.Tpo -c modules/graphics/opengl/VertexBuffer.cpp  -fPIC -DPIC -o modules/graphics/opengl/.libs/VertexBuffer.o
modules/graphics/opengl/VertexBuffer.cpp: In member function 'virtual void* love::graphics::opengl::VBO::map()':
modules/graphics/opengl/VertexBuffer.cpp:163:3: error: 'glGetBufferSubDataARB' was not declared in this scope
  163 |   glGetBufferSubDataARB(getTarget(), 0, (GLsizeiptr) getSize(), memory_map);
      |   ^~~~~~~~~~~~~~~~~~~~~
modules/graphics/opengl/VertexBuffer.cpp: In member function 'virtual void love::graphics::opengl::VBO::unmap()':
modules/graphics/opengl/VertexBuffer.cpp:181:3: error: 'glBindBufferARB' was not declared in this scope
  181 |   glBindBufferARB(getTarget(), vbo);
      |   ^~~~~~~~~~~~~~~
modules/graphics/opengl/VertexBuffer.cpp:187:2: error: 'glBufferDataARB' was not declared in this scope
  187 |  glBufferDataARB(getTarget(), (GLsizeiptr) getSize(), NULL,       getUsage());
      |  ^~~~~~~~~~~~~~~
modules/graphics/opengl/VertexBuffer.cpp: In member function 'virtual void love::graphics::opengl::VBO::bind()':
modules/graphics/opengl/VertexBuffer.cpp:197:3: error: 'glBindBufferARB' was not declared in this scope
  197 |   glBindBufferARB(getTarget(), vbo);
      |   ^~~~~~~~~~~~~~~
modules/graphics/opengl/VertexBuffer.cpp: In member function 'virtual void love::graphics::opengl::VBO::unbind()':
modules/graphics/opengl/VertexBuffer.cpp:205:3: error: 'glBindBufferARB' was not declared in this scope
  205 |   glBindBufferARB(getTarget(), 0);
      |   ^~~~~~~~~~~~~~~
modules/graphics/opengl/VertexBuffer.cpp: In member function 'virtual void love::graphics::opengl::VBO::fill(size_t, size_t, const void*)':
modules/graphics/opengl/VertexBuffer.cpp:220:20: error: 'glMapBufferARB' was not declared in this scope
  220 |    void *mapdata = glMapBufferARB(getTarget(), GL_WRITE_ONLY);
      |                    ^~~~~~~~~~~~~~
modules/graphics/opengl/VertexBuffer.cpp:228:5: error: 'glFlushMappedBufferRangeAPPLE' was not declared in this scope
  228 |     glFlushMappedBufferRangeAPPLE(getTarget(), (GLintptr) offset, (GLsizei) size);
      |     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
modules/graphics/opengl/VertexBuffer.cpp:231:4: error: 'glUnmapBufferARB' was not declared in this scope; did you mean 'glXSwapBuffers'?
  231 |    glUnmapBufferARB(getTarget());
      |    ^~~~~~~~~~~~~~~~
      |    glXSwapBuffers
modules/graphics/opengl/VertexBuffer.cpp:236:4: error: 'glBufferSubDataARB' was not declared in this scope; did you mean 'glXCopyBufferSubDataNV'?
  236 |    glBufferSubDataARB(getTarget(), (GLintptr) offset, (GLsizeiptr) size, data);
      |    ^~~~~~~~~~~~~~~~~~
      |    glXCopyBufferSubDataNV
modules/graphics/opengl/VertexBuffer.cpp: In member function 'bool love::graphics::opengl::VBO::load(bool)':
modules/graphics/opengl/VertexBuffer.cpp:261:2: error: 'glGenBuffersARB' was not declared in this scope
  261 |  glGenBuffersARB(1, &vbo);
      |  ^~~~~~~~~~~~~~~
modules/graphics/opengl/VertexBuffer.cpp:275:3: error: 'glBufferParameteriAPPLE' was not declared in this scope
  275 |   glBufferParameteriAPPLE(getTarget(), GL_BUFFER_FLUSHING_UNMAP_APPLE, GL_FALSE);
      |   ^~~~~~~~~~~~~~~~~~~~~~~
modules/graphics/opengl/VertexBuffer.cpp:278:2: error: 'glBufferDataARB' was not declared in this scope
  278 |  glBufferDataARB(getTarget(), (GLsizeiptr) getSize(), src, getUsage());
      |  ^~~~~~~~~~~~~~~
modules/graphics/opengl/VertexBuffer.cpp: In member function 'void love::graphics::opengl::VBO::unload(bool)':
modules/graphics/opengl/VertexBuffer.cpp:297:2: error: 'glDeleteBuffersARB' was not declared in this scope
  297 |  glDeleteBuffersARB(1, &vbo);
      |  ^~~~~~~~~~~~~~~~~~
make[3]: *** [Makefile:3575: modules/graphics/opengl/VertexBuffer.lo] Error 1
make[3]: Leaving directory '/home/darko/love-0.9.1/src'
make[2]: *** [Makefile:3643: all-recursive] Error 1
make[2]: Leaving directory '/home/darko/love-0.9.1/src'
make[1]: *** [Makefile:541: all-recursive] Error 1
make[1]: Leaving directory '/home/darko/love-0.9.1'
make: *** [Makefile:341: all] Error 2

[MikuAuahDark]

Consider upgrading to 0.9.2 and apply these patches. https://github.com/pfirsich/love-appimages/blob/master/fix_0_9_2.patch

[darkoverlordofdata]

Well this is odd - I thought I had replied to this. But I see now it didn't post. They said the solar storm on the 15th would disrupt the internet - I should have believed it. In any case, it doesn't affect the outcome. I applied the patches to 9.2, but it still had a slew of fatal syntax errors. I also found more examples of love2d games on itch with the same issue, for several versions, up to and including version 10. It seems you don't have backwards compatibility. I'm glad I discovered this before going much further with my prototype. Too bad, your engine actually works pretty well on Chromebook.

[slime73]

Some Linux distributions have changed the headers of certain dependencies (such as OpenGL) over the years in a manner that breaks compilation of some old apps, including old versions of love. The patch AuahDark linked works around those distro problems in specific situations. Overall it's not a problem caused by love, but by specific Linux distributions (and the drivers they ship).

Major versions (for example love 11, or love 10) are not compatible with code written for different major versions. But if you use love 11.4, all games that run on any love 11.x version up to 11.4 should work.

We encourage people to ship self-contained packages of games they make (e.g. appimages, which we provide), in part to avoid situations like this where Linux distros change things behind our back in a manner that breaks stuff. The concept of appimages didn't exist in mainstream Linux when love 0.9 was around though, so it's understandable that many love 0.9 games on Linux don't do that.

If you just want to run specific love games on your system, you can use prebuilt appimages for it: https://github.com/pfirsich/love-appimages/releases/tag/v3

[darkoverlordofdata]

Unfortunately, you don't have an appimage based on arm64, I do get these errors on Debian Bullseye on arm, as well as Kubuntu 21.10 on amd64. That's not to say I disbelieve you - it reinforces my view that linux has become terribly fragmented. I've also found cases where it lacks backwards compatibility at the kernel level for some usb devices that I used to use.I fear the 'decade of the linux desktop' is coming to an end for me. I've discovered that apple still supports my music recording equipment (my usb issue), so my next computer is likely to be the M1 mini. I'll check out love2d again once I've made the switch.

[slime73]

I don't think love 0.9 even officially supported arm64 architectures (it's too old for that), so I wouldn't be surprised if there are a number of things causing it to fail.