Failed to build freeglut

[telpalbrox]

First of all thank you for your work! Yesterday I was able to compile the latest version of the Nextcloud desktop client and I managed to run in my Surface RT.

I am trying now to build something else that requires ffmpeg and I'm not managing to compile it because freeglut is failing to compile.

First I got an error about <GL/glu.h> not being available. I went to MXE update port status spreadsheet and I saw that for freeglut in notes it says GL/* (add dependency!). The problem is that I don't really know what that means. Also now that I check it again it says 0 in the Status: builds, so I guess it is not working for anyone?

I tried to Google it and I got some random gl.h and glu.h files (attached in the gist) for MinGW and I was able to compile the library dll, but then the test program fails to compile in the linker phase with this error:

'armv7-w64-mingw32-gcc' -W -Wall -Werror -ansi -pedantic '/home/alberto/armmxe-shared/src/freeglut-test.c' -o '/home/alberto/armmxe-shared/usr/armv7-w64-mingw32/bin/test-freeglut.exe' `'armv7-w64-mingw32-pkg-config' glut --cflags --libs`
Package glu was not found in the pkg-config search path.
Perhaps you should add the directory containing `glu.pc'
to the PKG_CONFIG_PATH environment variable
Package 'glu', required by 'glut', not found
ld.lld: error: undefined symbol: __declspec(dllimport) glutInitWindowSize
>>> referenced by /tmp/freeglut-test-64c951.o:(main)

Is it possible to compile it? what exactly GL/* (add dependency!) means? Do I need to so something else to compile freeglut and ffmpeg?

Gist link with full logs for the first build, gl.h and glu.h files that I am using (I put them in ./usr/armv7-w64-mingw32/include/GL) and full log with the linker error.

Thank you in advance!

[treeswift]

It means that there are are several ways to provide the graphics library functionality ([Open]GL) and all of them have their drawbacks.

OpenGL is an API, and (less precisely) a generic name for a family of APIs (such as OpenGLES, i.e. OpenGL for embedded systems), designed to provide client applications with more or less direct access to the graphics card (GPU) and its accelerated rendering capabilities. The Microsoft-specific API on Windows systems that's used for the same purpose is called DirectX. OpenGL implementations on Windows typically wrap DirectX. (Less typical ones simulate accelerated GPU calculations with calculations on the CPU and then render the result on the screen; this is painfully slow and mostly usable for proof of concept or simulation purposes.)

There is a Windows library providing a very old version (1.1) of OpenGL API: https://learn.microsoft.com/en-us/windows/win32/opengl/opengl Version 1.1 implements profile 1, a "fixed rendering pipeline" with a predetermined set of operations without allowing the client to execute custom code ("shaders") on the GPU.

"Programmable pipeline" profiles are implemented by compatibility libraries such as MESA and ANGLE. Compiling ANGLE (which provides OpenGL ES for programs like the Chrome browser family) is a work in progress. MESA must compile by now, and actually executes most simple rendering payloads on the GPU rather than CPU.

GLU is an API family (implemented by a well-known library) that bridges GL (that operates on viewports) with the window system (that operates on application windows). I believe that some implementation of GLU is provided by MESA.

Some steps you can take to troubleshoot and maybe come up with an easy solution would be to build mesa, look up and hook up the artifacts it publishes. If, at the end of the day, it provides sufficient rendering speed, then we can add mesa as a freeglut dependency to provide accelerated rendering.

Our reluctance to settle on MESA so far has mostly been due to the fact that ANGLE provides a superior implementation of the same family of APIs, and some of much-needed applications would only settle for ANGLE.

[treeswift]

P.S. Googling and adding random header files WILL cause linker errors. What you need is actual implementation of the functionality they declare. IOW, headers are powerless without libraries (in most cases; some self-contained header libraries, typically C++ template libraries, exist).

A degree of general familiarity with the problem domain may also help:

• https://en.wikipedia.org/wiki/Hardware_acceleration
• https://en.wikipedia.org/wiki/Graphics_processing_unit
• https://en.wikipedia.org/wiki/OpenGL

[treeswift]

@pahaze — mesa not building GLU seems to be a lesser issue. Looking into configuration flags.

[treeswift]

Aha, "In the past, GLUT, GLU and the Mesa demos were released in conjunction with Mesa releases. But since GLUT, GLU and the demos change infrequently, they were split off into their own Git repositories: GLUT, GLU and Demos." from here

@pahaze — my guess is we want GLU. Suggesting a mesa-glu package src/mesa-glu.mk.

[treeswift]

On it — negotiating the GL profile expected by GLU and exposed by Mesa. Both libgallium_wgl.dll and the front-end DLL seem to contain the "glTexImage3D" string, but neither defines the symbol, and the import library does not contain it either.

[treeswift]

@telpalbrox — please do git fetch (or git pull), git checkout component/mesa-glu, and then run make freeglut again. Please keep us posted about any runtime errors you encounter.

[treeswift]

@telpalbrox — please check out component/mesa-glu. Looks like we have a first buildable of ffmpeg.

Some code paths may miss vectorization, and all bets are off regarding hardware video acceleration. Report anything that feels slow or weird.

[telpalbrox]

@treeswift Thanks for your detailed answer about how OpenGL and freeglut are connected.

I checked out the branch component/mesa-glu and I can successfully compile ffmpeg there.

Thank you very much! To me everything you are doing is still looking like magic. I appreciate your efforts.

About performance, as soon as I am able to compile something that uses ffmpeg I will report back. I understand that it may not be ideal but I think it is very cool to see it working.

[treeswift]

@telpalbrox Great!

FFMpeg builds a few command-line tools, the primary one being the eponymous command line A/V transcoder utility.