Alberto Salvia Novella

How to fix it, in source code: https://wiki.gentoo.org/wiki/Gcc_10_porting_notes/fno_common

I have found the culprit: same as in this bug report.

I have discovered that effectively the "curl" command will hang, even with those timeout settings.

Using a custom platform name doesn't prevent the linker to fail. The building process I'm following is as explained in the instructions. There should be something missing, either in the instructions or in the source code. Have you tested that (still) builds for you? The code I'm using is: buildLibs () { so "-buildLibs: removeArtefacts" rm --recursive "artefacts" yes "yes" | so "-buildLibs: exportCustomRecipes" python "1_export_custom.py" so "-buildLibs: compile" conan install . --build --options platform_name="linux" } buildEngine () { if [[ ! -d "${buildEngine}" ]]; then cp --recursive "${buildWorkspace}" "${buildEngine}..." cd "${buildEngine}.../darkmod_src" so "-buildEngine: cmake" cmake \ -DCMAKE_BUILD_TYPE="Release" \ -DTHIRDPARTY_PLATFORM_OVERRIDE="linux" \ -DCMAKE_EXE_LINKER_FLAGS="-no-pie" so "-buildEngine: makeMax" makeMax mv "${buildEngine}..." "${buildEngine}" fi } Maybe it's related with that "DCMAKE_EXE_LINKER_FLAGS". Without it I got a different error: /usr/bin/ld: ThirdParty/cmake_find_package/../artefacts/ffmpeg/lib/linux/libavcodec.a(me_cmp.o): relocation R_X86_64_32 against symbol `ff_pb_1' can not be used when making a PIE object; recompile with -fPIE /usr/bin/ld: ThirdParty/cmake_find_package/../artefacts/ffmpeg/lib/linux/libavcodec.a(sbrdsp.o): relocation R_X86_64_32 against `.rodata' can not be used when making a PIE object; recompile with -fPIE /usr/bin/ld: ThirdParty/cmake_find_package/../artefacts/ffmpeg/lib/linux/libavcodec.a(xvididct.o): relocation R_X86_64_32 against `.rodata' can not be used when making a PIE object; recompile with -fPIE /usr/bin/ld: ThirdParty/cmake_find_package/../artefacts/ffmpeg/lib/linux/libavcodec.a(aacpsdsp.o): relocation R_X86_64_32 against `.rodata' can not be used when making a PIE object; recompile with -fPIE /usr/bin/ld: ThirdParty/cmake_find_package/../artefacts/ffmpeg/lib/linux/libavutil.a(float_dsp.o): relocation R_X86_64_32 against `.rodata' can not be used when making a PIE object; recompile with -fPIE /usr/bin/ld: ThirdParty/cmake_find_package/../artefacts/ffmpeg/lib/linux/libswresample.a(audio_convert.o): relocation R_X86_64_32 against `.rodata' can not be used when making a PIE object; recompile with -fPIE /usr/bin/ld: ThirdParty/cmake_find_package/../artefacts/ffmpeg/lib/linux/libswresample.a(rematrix.o): relocation R_X86_64_32 against `.rodata' can not be used when making a PIE object; recompile with -fPIE /usr/bin/ld: ThirdParty/cmake_find_package/../artefacts/ffmpeg/lib/linux/libswresample.a(resample.o): relocation R_X86_64_32 against `.rodata' can not be used when making a PIE object; recompile with -fPIE /usr/bin/ld: ThirdParty/cmake_find_package/../artefacts/ffmpeg/lib/linux/libswscale.a(hscale_fast_bilinear_simd.o): relocation R_X86_64_32S against `.text.unlikely' can not be used when making a PIE object; recompile with -fPIE /usr/bin/ld: ThirdParty/cmake_find_package/../artefacts/ffmpeg/lib/linux/libswscale.a(swscale.o): relocation R_X86_64_32S against `.rodata' can not be used when making a PIE object; recompile with -fPIE /usr/bin/ld: ThirdParty/cmake_find_package/../artefacts/ffmpeg/lib/linux/libswscale.a(input.o): relocation R_X86_64_32 against `.rodata' can not be used when making a PIE object; recompile with -fPIE /usr/bin/ld: ThirdParty/cmake_find_package/../artefacts/ffmpeg/lib/linux/libswscale.a(output.o): relocation R_X86_64_32 against `.rodata' can not be used when making a PIE object; recompile with -fPIE /usr/bin/ld: ThirdParty/cmake_find_package/../artefacts/ffmpeg/lib/linux/libswscale.a(rgb2rgb.o): relocation R_X86_64_32S against `.rodata' can not be used when making a PIE object; recompile with -fPIE /usr/bin/ld: ThirdParty/cmake_find_package/../artefacts/ffmpeg/lib/linux/libswscale.a(rgb_2_rgb.o): relocation R_X86_64_32 against `.rodata' can not be used when making a PIE object; recompile with -fPIE /usr/bin/ld: ThirdParty/cmake_find_package/../artefacts/ffmpeg/lib/linux/libswscale.a(scale.o): relocation R_X86_64_32 against `.rodata' can not be used when making a PIE object; recompile with -fPIE /usr/bin/ld: ThirdParty/cmake_find_package/../artefacts/ffmpeg/lib/linux/libswscale.a(yuv2rgb.o): relocation R_X86_64_32S against `.rodata' can not be used when making a PIE object; recompile with -fPIE collect2: error: ld returned 1 exit status make[2]: *** [CMakeFiles/TheDarkMod.dir/build.make:8570: thedarkmod.custom] Error 1 make[1]: *** [CMakeFiles/Makefile2:83: CMakeFiles/TheDarkMod.dir/all] Error 2 make: *** [Makefile:91: all] Error 2

Yes, but still this is an issue in the installer too. The installer must expect the network to fail from time to time. It remembers me of this. I tell you warranted that, at least when using the curl command, if I don't set a timeout to certain servers the connection will hang forever in many situations. For example GitHub will hang the connection from time to time to prevent bots from retrieving repository info without using the API. But if I set a timeout and a retry it will always work. Find what? Then anything you change on the ".ini" won't take effect, will it? The least surprising behavior would be that you can close the window at any time. A good enough solution would be that the sub-process continues downloading the current file, and after that it doesn't continue anymore: while processIsAlive(parent) && file < len(files) { downloadFile (files[file]) file++ }

The traceroute fails to continue at: 13 netcup-gw.bbr01.anx84.nue.de.anexia-it.net (144.208.211.31) Around 17:25 UTC. This looks as a double issue to me. The server is unreachable, and the installed cannot tell.

Perhaps the answer is that libraries are rebuilt automatically when building the game, and there's no such thing as a sub-folder for platform.

HANGS AT MANIFEST For me running the installer with "--unattended" result in a hang from time to time at: Downloading "http://tdm.frydrych.org/mirror/zipsync/release/release200/manifest.iniz"... It seems to depend on how busy the server is at that moment. After many tries it couldn't work at all, but if you try later it could always work. OTHER FLAWS Editing the .ini file doesn't work. The installer overwrites it before starting the download. Also closing the installer window doesn't interrupt the download process, only the window. The terminal still prints as downloading. NEEDS TO TIMEOUT I would check in the code that the connection times-out after a second if it doesn't receive a response. Then it should retry it, for example, 3 times after 30 seconds plus a random number from 0 to 10. For example when I use "curl" inside my code, I always do like this: curl --silent --connect-timeout 1 --retry 3 memory_info.txt

The decision is between the hardness of typing those git commands, versus the frictions derived from all members having to work in the same copy at the same time.

How to use git Get: git clone --depth 1 --shallow-submodules "[url]" Set: git add --all; git commit --message="[summary]"; git push Or even better, use gitu.

I'm writing a recipe to package the game for Linux, and it to work system wide. The recipe compiles everything from source-code, as usually required by Linux distributions for security. If I compile as it is, everything is fine. But if I also try to compile the third party libraries by myself, even when they compile successfully, the process fails when linking to openal: There's also a second problem. "ThirdParty/cmake_find_package/tdm_find_package.cmake" expects gcc to be version 5, but my Linux distribution only offers gcc 10: If I compile libraries by myself, that gcc dir is "gcc10". Although this is easy fixed by substituding the string with:

In my case changing from 64-bit to 32-bit textures solves the glitches, on Radeon HD 5870.

@stgatilovCould loading saves among different stable builds result in a crash?

For my Linux operating system, I have created a recipe for building and packaging the game. So the binaries are compiled from source, for security. The thing is that when I load a saved game, I'm told that the revision of the game is zero. Like this: I don't know if that's the intended behavior, of that if you can set the revision while building. As the compilation guide says nothing about it.

Having it installed as a system wide application makes more sense to me. It also makes more sense only displaying info or errors that need compulsory attendance of a human. Everything else is better automated or prevented all together. That said most of my software design ideas come from The Unix Philosophy, in case you are curious.

@freyk

I have created an software that can install The Dark Mod in any Linux system wide. https://gitlab.com/es20490446e/darkmod-linux

Streaming now.

Streaming now at:

Streaming now at: https://www.twitch.tv/alberto_salvia_novella

If you are playing some Dark Mod campaign, you can let other people join you by streaming it. If that's the case mention so here in the very moment you are starting the stream, indicating which campaign you are playing.

Just played it through, great map!

I made an improved PKGBUILD. If you wanted a pull request, just let me know.

I mean that if you create a Pacman package using the Debian unstable package as binary source, running the binary leads to `WXU_3.0.5' not found. Even when the Debian package is compiled using libwxgtk3.0-dev 3.0.4, that's the weird part.