-
Posts
160 -
Joined
-
Last visited
-
Days Won
1
Posts posted by Alberto Salvia Novella
-
-
I have found the culprit: same as in this bug report.
- 1
-
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
-
16 hours ago, cabalistic said:
I can ask my ISP about it as that's their infrastructure
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.
8 hours ago, stgatilov said: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.
8 hours ago, stgatilov said:Where did you find it?
Find what?
8 hours ago, stgatilov said:Installer always does that.
Then anything you change on the ".ini" won't take effect, will it?
8 hours ago, stgatilov said:I think I should tie closing GUI to canceling download in the last page, and simply block the cross icon at all the other moments.
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
-
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.
- 1
-
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:
Quote/usr/bin/ld: ThirdParty/cmake_find_package/../artefacts/openal/lib/lnx64_s_gcc10_rel_stdcpp/libopenal.a(ALu.c.o):(.rodata+0x3bf60): multiple definition of `FuMa2N3DScale'; ThirdParty/cmake_find_package/../artefacts/openal/lib/lnx64_s_gcc10_rel_stdcpp/libopenal.a(ALc.c.o):(.rodata+0xf40): first defined here
/usr/bin/ld: ThirdParty/cmake_find_package/../artefacts/openal/lib/lnx64_s_gcc10_rel_stdcpp/libopenal.a(ALu.c.o):(.rodata+0x3bfa0): multiple definition of `SN3D2N3DScale'; ThirdParty/cmake_find_package/../artefacts/openal/lib/lnx64_s_gcc10_rel_stdcpp/libopenal.a(ALc.c.o):(.rodata+0xf80): first defined here
/usr/bin/ld: ThirdParty/cmake_find_package/../artefacts/openal/lib/lnx64_s_gcc10_rel_stdcpp/libopenal.a(ALu.c.o):(.rodata+0x3bfe0): multiple definition of `N3D2N3DScale'; ThirdParty/cmake_find_package/../artefacts/openal/lib/lnx64_s_gcc10_rel_stdcpp/libopenal.a(ALc.c.o):(.rodata+0xfc0): first defined here
/usr/bin/ld: ThirdParty/cmake_find_package/../artefacts/openal/lib/lnx64_s_gcc10_rel_stdcpp/libopenal.a(bformatdec.c.o):(.rodata+0x2e0): multiple definition of `SN3D2N3DScale'; ThirdParty/cmake_find_package/../artefacts/openal/lib/lnx64_s_gcc10_rel_stdcpp/libopenal.a(ALc.c.o):(.rodata+0xf80): first defined here
/usr/bin/ld: ThirdParty/cmake_find_package/../artefacts/openal/lib/lnx64_s_gcc10_rel_stdcpp/libopenal.a(bformatdec.c.o):(.rodata+0x320): multiple definition of `N3D2N3DScale'; ThirdParty/cmake_find_package/../artefacts/openal/lib/lnx64_s_gcc10_rel_stdcpp/libopenal.a(ALc.c.o):(.rodata+0xfc0): first defined here
/usr/bin/ld: ThirdParty/cmake_find_package/../artefacts/openal/lib/lnx64_s_gcc10_rel_stdcpp/libopenal.a(bformatdec.c.o):(.rodata+0x2a0): multiple definition of `FuMa2N3DScale'; ThirdParty/cmake_find_package/../artefacts/openal/lib/lnx64_s_gcc10_rel_stdcpp/libopenal.a(ALc.c.o):(.rodata+0xf40): first defined here
/usr/bin/ld: ThirdParty/cmake_find_package/../artefacts/openal/lib/lnx64_s_gcc10_rel_stdcpp/libopenal.a(panning.c.o):(.rodata+0x1360): multiple definition of `FuMa2N3DScale'; ThirdParty/cmake_find_package/../artefacts/openal/lib/lnx64_s_gcc10_rel_stdcpp/libopenal.a(ALc.c.o):(.rodata+0xf40): first defined here
/usr/bin/ld: ThirdParty/cmake_find_package/../artefacts/openal/lib/lnx64_s_gcc10_rel_stdcpp/libopenal.a(panning.c.o):(.rodata+0x13e0): multiple definition of `N3D2N3DScale'; ThirdParty/cmake_find_package/../artefacts/openal/lib/lnx64_s_gcc10_rel_stdcpp/libopenal.a(ALc.c.o):(.rodata+0xfc0): first defined here
/usr/bin/ld: ThirdParty/cmake_find_package/../artefacts/openal/lib/lnx64_s_gcc10_rel_stdcpp/libopenal.a(panning.c.o):(.rodata+0x13a0): multiple definition of `SN3D2N3DScale'; ThirdParty/cmake_find_package/../artefacts/openal/lib/lnx64_s_gcc10_rel_stdcpp/libopenal.a(ALc.c.o):(.rodata+0xf80): first defined here
collect2: error: ld returned 1 exit status
make[2]: *** [CMakeFiles/TheDarkMod.dir/build.make:8570: thedarkmod.x64] Error 1
make[1]: *** [CMakeFiles/Makefile2:83: CMakeFiles/TheDarkMod.dir/all] Error 2
make: *** [Makefile:91: all] Error 2There'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:
Quoteif (UNIX)
if (CMAKE_SIZEOF_VOID_P EQUAL
set(PACKAGE_PLATFORM "lnx64_s_gcc5_rel_stdcpp")
set(PACKAGE_PLATFORM_DEBUG "lnx64_s_gcc5_rel_stdcpp")
else ()
set(PACKAGE_PLATFORM "lnx32_s_gcc5_rel_stdcpp")
set(PACKAGE_PLATFORM_DEBUG "lnx32_s_gcc5_rel_stdcpp")
endif ()If I compile libraries by myself, that gcc dir is "gcc10". Although this is easy fixed by substituding the string with:
Quotesed "s|_gcc[0-9]*_|_gcc${gccVersion}_|g" "ThirdParty/cmake_find_package/tdm_find_package.cmake"
-
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.
- 2
-
@freyk
- 2
-
I have created an software that can install The Dark Mod in any Linux system wide.
- 2
-
Streaming now.
-
Streaming now at:
- 1
-
Streaming now at:
- 1
-
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.
-
18 hours ago, greebo said:
there are Debian packages which are binaries
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.
Unable to link openal during compilation
in TDM Tech Support
Posted
How to fix it, in source code:
https://wiki.gentoo.org/wiki/Gcc_10_porting_notes/fno_common