The VideoLAN Forums

I'm up to "Configure" under "Configuring the Build" at the step labeled "Execute the build configuration script."

../extras/package/win32/configure.sh --host=i686-w64-mingw32 --build=x86_64-pc-linux-gnu

This ends with:
"configure: error: Could not find lua. Lua is needed for..."

Lua 5.2.4 is already installed via an earlier step on the Wiki page:
apt-get install lua5.2

Other sites say I should install liblua5.2-dev, so I successfully did:
apt-get install liblua5.2-dev

However, I still get the "Could not find lua" message.

I tried installing lua5.1 and liblua5.1-dev as well but that didn't make any difference.

I'm trying to build from a "minimal" install of Ubuntu 18.04.

Any help would be greatly appreciated.

Thanks!

Good news: The original problem was solved (somehow I skipped over "make" for the 3rd party libs altogether earlier)

Not-so-good News: "make" fails due to Java 10 not supporting code targeting Java 1.5. Fortunately this is easily solved by replacing Java 10 with Java 8.

Bad News: I now get the following messages that cause make to fail: Is this because the recommendation to get "ia32-libs" earlier refers to a resource that no longer exists? My understanding is that the new, more complicated solution is to:
1) Know the lib names for all missing dependencies
2) add ":i386" after the lib names (so something like 'apt-get install libmissing:i386')

Or is something else wrong?

I'm not alone in encountering this problem. It's the last problem listed on this other site by another Ubuntu 18 user.

Hi, to compile on windows, the easiest solution would be to use the docker image. See this guide for more information: https://gitlab.com/garfvl/local-vlc-compile-env

Hi, to compile on windows, the easiest solution would be to use the docker image. See this guide for more information: https://gitlab.com/garfvl/local-vlc-compile-env

Thank you very much for the suggestion. I am aware of Docker images as an option, but haven't gone down that road yet.

Ideally I'd like to understand why the build process isn't working, not just replace the build environment. That would help me (obviously) and could lead to improvements to the Win32Compile guide for other people, so hopefully somebody knows what's wrong.

Not a lot of people are compiling for windows 32bit so it might be difficult to find an answer :/

Not a lot of people are compiling for windows 32bit so it might be difficult to find an answer :/

The Win32Compile guide applies to both Windows 32-bit and 64-bit.

I'm hitting the same problem.

What's the solution?
I'm building for 64-bit Windows, using the guide.

I have in the past tried to use the Win32Compile page, sometimes it has worked, other times I've had to disable one or two plugins or contribs, but generally when trying to rebuild after grabbing some later VLC code I use to have a feeling of dread that it might not build and there would be some investigating to do.

It's just way better to use the docker system. Otherwise you can never be sure you are building on a system that has the right version of X, Y and Z.

I actually fixed the problem above by pointing CC and LD in Makefile.mingw at the x86_64-w64-mingw32 versions, and correcting the library path to point to /usr/x86_64-w64-mingw32/lib, and the make actually finished!

But now where is the VLC zip or exes I can run on Windows? The instructions for packaging from the WIKI don't work:

Ugh. Apparently that huge effort was just for the plugins! The guide could be clearer.

Now, I've got to install a newer version of Ubuntu and rerun everything because 18.04 LTS doesn't offer the GCC 8 toolchain which is needed to avoid errors I'm hitting.

Seriously, use the docker image from the CI

Seriously, use the docker image from the CI

Docker is fine and dandy if your only goal is to build the latest VLC. I needed to build 3.0.x and also 2.2.0-rc1. The Docker images, which appear to start in December 2017, don't work with code from November 2014 (2.2.0-rc1). Obviously similar issues apply to a multitude of other old VLC versions that users/devs may need to build for various reasons.

My goal was to fix Ticket 20730 (FLV seeking slow) in both the current version of VLC and the oldest (lowest-overhead) version that doesn't have problems playing FLV/HDS streams. Versions 2.2.0 through 2.2.8 have audio playback problems, versions before 2.2.0-rc1 have audio and/or video problems, and 2.2.0-rc2 has unacceptable stability problems. Building 2.2.0-rc1 with the Win32Compile guide didn't work for me with various versions of Ubuntu. Building 2.2.0-rc1 with the latest Docker image was eventually possible but only after many, many of hours of troubleshooting and source modifications.

Using a build environment better suited for the older code would have been far more reasonable, and it would have been more possible if build dependency version info was readily available. As long as some of the build dependencies for VLC don't maintain backwards compatibility, guides like the one on the Win32Compile will almost never be usable without build dependency version information. Surely it isn't a priority, but if such version information can eventually be provided that would be quite helpful.

Using a build environment better suited for the older code would have been far more reasonable, and it would have been more possible if build dependency version info was readily available. As long as some of the build dependencies for VLC don't maintain backwards compatibility, guides like the one on the Win32Compile will almost never be usable without build dependency version information. Surely it isn't a priority, but if such version information can eventually be provided that would be quite helpful.

We jumped to docker-based build with versionned Dockerfile and versionned contrib to be able to compile older version, but it's post 2.x.x version. Bisecting on very old VLC version is hard, and doing so on windows is probably like shooting you in the foot. Maybe there is a simpler way to find and fix your issue ?

We jumped to docker-based build with versionned Dockerfile and versionned contrib to be able to compile older version, but it's post 2.x.x version. Bisecting on very old VLC version is hard, and doing so on windows is probably like shooting you in the foot. Maybe there is a simpler way to find and fix your issue ?

That would have been nice, but I don't think so. VLC depends on ffmpeg's FLV demuxer, and that demuxer's seek function is trash (reads every tag/packet from the start of the file until the desired timestamp is found). Also that demuxer returns the duration of an FLV video as whatever the last timestamp happens to be. This makes a mess when the FLV file contains HDS stream data (timestamp wraps around after about a month, so the duration is usually absurd).

The problems have been fixed here, but the fixes would need to be refined quite a bit before they could reasonably be incorporated into any official code for VLC, ffmpeg, or anything else.

Unfortunately, 2.2.x is beyond hope for security reasons.

And I agree that the FLV demuxer is of very dubious quality.

Unfortunately, 2.2.x is beyond hope for security reasons.

It should go without saying that the 2.2.0-rc1 builds that I've made are for my own personal use, primarily on older (resource-limited) hardware, and only for playing local/offline copies of FLV/HDS data.

As far as 2.2.x in general, 2.2.8 at least does build with the Docker image as of a couple of months ago with few or no changes required.

As security issues eventually become a problem for 3.0.x is there any chance that old Docker containers will be taken offline? Or will they remain online to further reduce dependence on the Win32Compile page for a pretty wide span of releases in the future (late 2.2.x to present)?