Update to the README.md — RE: building instructions for MSYS2 about tsmuxer

[justdan96]

I think I'm nearly ready to close the issue. I was having a think and there isn't any harm in including an option for people to supply their own libraries, in case they aren't supplied with the distribution or are out of date. The readme can be updated with instructions on how to do that and CMake needs some editing.

I also managed to get a MacOS build working with osxcross and that required building the libraries from scratch, so it may well be a requirement for at least that build. I'll test a bit further and update the readme with an osxcross section.

The readme will be updated soon, I'll be removing the MSVC section since I won't be looking to actively maintain it over the long term. With native Linux, MXE and osxcross working on Ubuntu to create builds for the 3 main platforms I'll look to get a Docker container created so the builds can be created very easily.

[justdan96]

First update to CMake and readme just pushed in, further updates to follow.

[justdan96]

I've been working on getting the build working correctly with MXE recently so I haven't looked at MSYS in a while. If you have the correct instructions please submit a pull request.

[filler56789]

Sorry, but currently I have no plans to test the recent modifications in your tsMuxeR repository. Apparently CMake will detect that both zlib and freetype2 are not "installed" on my MSYS2 environment and probably the compilation process will not even start. I suggested the inclusion of the source-codes of both zlib and freetype2 in your tsMuxeR repository for a good reason but you chose to reject my suggestion. This is the reason why I created my own tsMuxeR repository instead of forking yours.

[xavery]

Created #23 which should - I believe - fix issues with building on MSYS2, at least it did for me. @filler56789 do kindly check if the tree builds for you after merging these changes.

[filler56789]

Okay, since @justdan96 decided to re-open this issue...

— first of all, nope, no pull requests from me in the foreseeable future;
— now,

You can safely get rid of

needed base-devel
mingw-w64-i686-toolchain
mingw-w64-x86_64-toolchain
libelf-devel

In my guide at Videohelp I already showed what is the minimum necessary and sufficient.

There is no need to duplicate CMake, i.e., no need to have both 32-bit and 64-bit editions;
CMake should have its own directory under "/" and its "bin" folder must be included in the "PATH" environment variable of MSYS2; it's better to download CMake from its official web site and extract the contents of the installer/archive to the chosen location;

git is BLOATWARE 😠 and unless the user is also a Linux zealot there is no point in wasting 300 MB of HDD space to store it; the portable editions that I indicated in my guide at Videohelp-dot-com are sufficient;

Regarding freetype2 and zlib: it's pointless to install both the 32-bit and 64-bit editions of these libraries when you can build both Win32 and Win64 binaries with the same source-code alright. This is the reason why my tsMuxeR repository already includes freetype2 and zlib;

I don't know how to deal with QT5 so I will ignore it. I think that because of the people who have no interest in the GUI your tsMuxeR repository should offer two build scripts, one which excludes the GUI and the other for the people who have already installed QT5.

[justdan96]

My understanding of Msys2 was that there were the 3 subsystems, Msys2 for package management, Mingw32 for compiling 32-bit programs and Mingw64 for compiling 64-bit programs. If it's not the case then we can definitely correct those instructions.

The readme can surely be updated to remove some of the dependencies and I would agree with removing Git (since you would need to have it installed to clone the repo anyway) and Qt5 (since you may not actually want to compile the GUI).

We'll have to agree to disagree on freetype2 and zlib - we've both stated our positions here so there isn't any new ground to cover.

We can add an option to CMake to allow compiling of the GUI as opt-in. I think that does make sense since it might not be something everyone requires.

[filler56789]

It seems a lot of misunderstanding has been going on since August.
When I wrote

1) In the README of TSMuxer, instead of "To compile tsMuxer and tsMuxerGUI on Windows..." you should have written "To compile tsMuxer and tsMuxerGUI with Microsoft Visual Studio". Stop denying the existence of MSYS2 and MinGW-64🙂

I wasn't asking for instructions on how to compile tsMuxeR with MinGW-w64 and MSYS2.
I simply meant you should have written "MS Visual Studio" instead of Windows.

Regular users of MSYS + MinGW-w64 expect to find a ready-made configure OR a configure.ac OR a (functional) Makefile OR a (functional) CMakeLists.txt. People who write code to be compiled with GCC usually don't take the time to write special instructions for the "MSYS folks". And we the "MSYS folks" usually don't need them because we already know the unix-like universe is weird and its regular inhabitants don't care too much about how things work on Windows🙂

So, now I think that you can get rid of both the MSYS instructions and the Linux instructions and keep only the MSVC ones.

[filler56789]

Anyway, IMNSHO the main README.md needs only to state the common and general requirements for ALL «building environments»:

— CMake;
— freetype2 and zlib installed;
— QT5 for the people who want /need a GUI.

[filler56789]

Oooops, it seems my latest thumbs-up was exceedingly optimistic.....

[/d/tests/tsmuxer3/build]
<MINGW32> make
Scanning dependencies of target mediation
[  1%] Building CXX object libmediation/CMakeFiles/mediation.dir/fs/directory.cpp.obj
[  3%] Building CXX object libmediation/CMakeFiles/mediation.dir/types/types.cpp.obj
[  5%] Building CXX object libmediation/CMakeFiles/mediation.dir/system/terminatablethread.cpp.obj
In file included from D:/TESTS/tsMuxer3/libmediation/system/terminatablethread.cpp:1:
D:/TESTS/tsMuxer3/libmediation/system/terminatablethread.h:28:7: error: 'thread' in namespace 'std' does not name a type
   28 |  std::thread m_thread;
      |       ^~~~~~
D:/TESTS/tsMuxer3/libmediation/system/terminatablethread.h:5:1: note: 'std::thread' is defined in header '<thread>'; did you forget to '#include <thread>'?
    4 | #include <thread>
  +++ |+#include <thread>
    5 |
D:/TESTS/tsMuxer3/libmediation/system/terminatablethread.h: In member function 'void TerminatableThread::join()':
D:/TESTS/tsMuxer3/libmediation/system/terminatablethread.h:18:7: error: 'm_thread' was not declared in this scope; did you mean '_threadid'?
   18 |   if (m_thread.joinable()) {
      |       ^~~~~~~~
      |       _threadid
In file included from r:\msys2x86\mingw\32\main\i686-w64-mingw32\include\c++\9.2.0\cassert:44,
                 from D:/TESTS/tsMuxer3/libmediation/system/terminatablethread.cpp:3:
D:/TESTS/tsMuxer3/libmediation/system/terminatablethread.cpp: In static member function 'static void TerminatableThread::run(TerminatableThread*)':
D:/TESTS/tsMuxer3/libmediation/system/terminatablethread.cpp:10:13: error: 'class TerminatableThread' has no member named 'm_thread'
   10 |   assert(t->m_thread.get_id() == std::thread::id() &&
      |             ^~~~~~~~
D:/TESTS/tsMuxer3/libmediation/system/terminatablethread.cpp:10:39: error: 'std::thread' has not been declared
   10 |   assert(t->m_thread.get_id() == std::thread::id() &&
      |                                       ^~~~~~
D:/TESTS/tsMuxer3/libmediation/system/terminatablethread.cpp:12:6: error: 'class TerminatableThread' has no member named 'm_thread'
   12 |   t->m_thread = std::thread([t]() { t->thread_main(); });
      |      ^~~~~~~~
D:/TESTS/tsMuxer3/libmediation/system/terminatablethread.cpp:12:22: error: 'thread' is not a member of 'std'
   12 |   t->m_thread = std::thread([t]() { t->thread_main(); });
      |                      ^~~~~~
D:/TESTS/tsMuxer3/libmediation/system/terminatablethread.cpp:4:1: note: 'std::thread' is defined in header '<thread>'; did you forget to '#include <thread>'?
    3 | #include <cassert>
  +++ |+#include <thread>
    4 |
make[2]: *** [libmediation/CMakeFiles/mediation.dir/build.make:92: libmediation/CMakeFiles/mediation.dir/system/terminatablethread.cpp.obj] Error 1
make[1]: *** [CMakeFiles/Makefile2:97: libmediation/CMakeFiles/mediation.dir/all] Error 2
make: *** [Makefile:130: all] Error 2

[filler56789]

One more thing...

apparently CMake did not look for freetype2 and generated the makefile anyway.
Since the CLI executable cannot work without freetype2, CMake should have returned a fatal error, me thinks.

[justdan96]

I did a bit of research - your Mingw32 installation has to support POSIX threads. Some info here:

dashpay/dash#1751
http://www.cplusplus.com/forum/beginner/189974/

Can you check if your C++ installation comes with POSIX threads support?

[filler56789]

P.S.: and oh by the way, one of the problems for the users of MSYS2 is this:

unless defined otherwise during the ./configure, dependencies are installed by default under /usr,

whereas the stupid pkg-config by default looks for them under /mingw32 and /mingw64.
😒

[filler56789]

Can you check if your C++ installation comes with POSIX threads support?

Apparently the answer is YES.
Because I compile my own GCC+MingW stuff by using the scripts created by Zeranoe and modified by nevcairiel:

https://files.1f0.de/mingw/

[justdan96]

On Windows it isn't supposed to be using freetype2, maybe the OS detection is a bit off?

[filler56789]

On Windows it isn't supposed to be using freetype2

0_0

I wasn't aware of that.

Can you explain to me why that library is not required on a Windows build?

[filler56789]

FWIW: I used MSYS1 from 2010 through 2016 and I've been using MSYS2 from 2016 until today.
This is the first time I see this type of error.
ALL of the MSYS setups I have used have ALWAYS used pthreads-w32.

Which makes me ask: what was the point of the latest changes in your tsMuxeR code,
besides making it impossible to compile with a normal and healthy MSYS2 setup?

[qyot27]

P.S.: and oh by the way, one of the problems for the users of MSYS2 is this:
unless defined otherwise during the ./configure, dependencies are installed by default under /usr,
whereas the stupid pkg-config by default looks for them under /mingw32 and /mingw64.

The default install directories are controlled by the project's buildsystem, not MSys2. And the vast majority of software using autotools or hand-crafted systems (x264 or FFmpeg, for example) hardcode /usr/local as the default path, expecting the user to use --prefix= or equivalent to change it if there's a reason you need it somewhere else (notably, when cross-compiling, which is still technically what's going on in MSys2, because MinGW[-w64] is itself a cross environment). Alternative systems like CMake or meson also assume /usr/local, but likely control that when their binaries are built, rather than putting it in the configuration script.

What MSys2 does do is set PKG_CONFIG_PATH to the corresponding /lib/pkgconfig directory under MINGW_MOUNT_POINT, which is itself defined as the value of MINGW_PREFIX (/mingw32 on MINGW32 and /mingw64 on MINGW64), for the regular MSYS2 subsystem it looks at its global root dirs, the way typical *nixen would do. This logic is located in /etc/profile.

Apparently the answer is YES.
Because I compile my own GCC+MingW stuff by using the scripts created by Zeranoe and modified by nevcairiel:

What does gcc -v say?

[filler56789]

What does gcc -v say?

[~]
<MINGW64> gcc -v
Using built-in specs.
COLLECT_GCC=R:\MSYS2x86\mingw\64\main\bin\gcc.exe
COLLECT_LTO_WRAPPER=r:/msys2x86/mingw/64/main/bin/../libexec/gcc/x86_64-w64-mingw32/9.2.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../source/gcc-9.2.0/configure --build=i686-pc-mingw32 --target=x86_64-w64-mingw32 --disable-shared --enable-static --disable-nls --disable-multilib --prefix=/shipyard/mingw-w64-x86_64 --with-sysroot=/shipyard/mingw-w64-x86_64 --with-mpc=/shipyard/pkgs/mpc/mpc-1.1.0-i686 --with-mpfr=/shipyard/pkgs/mpfr/mpfr-4.0.2-i686 --with-gmp=/shipyard/pkgs/gmp/gmp-6.1.2-i686 --with-isl=/shipyard/pkgs/isl/isl-0.21-i686 --enable-languages=c,c++ --enable-fully-dynamic-string --enable-lto
Thread model: win32
gcc version 9.2.0 (GCC)

1. I didn't ask you to explain to me what I already know, I simply described a frequent annoyance... and I am pretty aware that the problem is not on the nixoidverse itself, the problem is in the way MSYS2 was designed...

[justdan96]

First of all a reminder to all we do have a code of conduct we expect everyone to abide by: https://www.w3.org/Consortium/cepc/ Keep it civil.

Secondly the subtitles rendering system is switched based on platform, you can see the 2 systems here: https://github.com/justdan96/tsMuxer/tree/master/tsMuxer/osdep

Thirdly from the gcc -v output we can see it is using win32 threads.

I think we have to say we can't troubleshoot each specific build environment as we are straying further and further away from tsMuxer issues.

[filler56789]

@justdan96 — many thanks for NOT answering my question.
Your "keep it civil" bullshît is just a way to try to hide the fact that you don't know very well what you're doing
(OR trying to do).
Good-bye.

[justdan96]

Okay I'm putting a stop to this now