00:37 <+bridge> [ddnet] nah im fairly sure that was it 00:37 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/696851047427211324/Screen_Shot_2020-04-06_at_5.36.17_PM.png 00:37 <+bridge> [ddnet] look i tried changing gfx_highdpi 1 00:37 <+bridge> [ddnet] and the font changed 00:37 <+bridge> [ddnet] and my fans spin on 10.6.2 now 00:38 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/696851230143545414/Screen_Shot_2020-04-06_at_5.37.53_PM.png 00:38 <+bridge> [ddnet] now turned off highdpi 00:38 <+bridge> [ddnet] and font's back to normal, fans stopped spinning 00:38 <+bridge> [ddnet] @Learath2 @heinrich5991 00:39 <+bridge> [ddnet] im prety sure the versions that caused fan spinning 00:39 <+bridge> [ddnet] didnt even have this option to turn off 00:41 <+bridge> [ddnet] finding this + the result of the bisects pretty strongly points to the high dpi being the cause of all of these problems 01:44 <+bridge> [ddnet] <> https://cdn.discordapp.com/attachments/293493549758939136/696868086300672120/screenshot_2020-04-07_01-44-35.png 01:45 <+bridge> [ddnet] <> https://cdn.discordapp.com/attachments/293493549758939136/696868091795210541/screenshot_2020-04-07_01-44-36.png 01:45 <+bridge> [ddnet] <> what is this 01:45 <+bridge> [ddnet] someone is spoofing servers 01:45 <+bridge> [ddnet] bumm with egirls 01:45 <+bridge> [ddnet] <> when i join second server i join first lol 01:45 <+bridge> [ddnet] do not join it 01:45 <+bridge> [ddnet] <> why 01:45 <+bridge> [ddnet] yep dont join 01:46 <+bridge> [ddnet] theyre probably trying to get playerips 01:46 <+bridge> [ddnet] ye 01:46 <+bridge> [ddnet] <> oh 01:46 <+bridge> [ddnet] can u still see it? 01:46 <+bridge> [ddnet] <> ye 01:46 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/696868444905144500/unknown.png 01:46 <+bridge> [ddnet] mm 01:46 <+bridge> [ddnet] <> oh 01:46 <+bridge> [ddnet] wtf 01:47 <+bridge> [ddnet] and they got several ips 01:47 <+bridge> [ddnet] its literally 01:47 <+bridge> [ddnet] just some dbag with his home internet doing it 01:47 <+bridge> [ddnet] look up his ip 01:47 <+bridge> [ddnet] the servers with ticks are real tho 01:47 <+bridge> [ddnet] nice feature to have rn 01:47 <+bridge> [ddnet] i dont see the fake servers now 01:47 <+bridge> [ddnet] 😄 01:47 <+bridge> [ddnet] <> same 01:47 <+bridge> [ddnet] sometimes they appear 01:48 <+bridge> [ddnet] rip 01:48 <+bridge> [ddnet] i wonder who is doing this 01:48 <+bridge> [ddnet] <> time to ddos him 01:48 <+bridge> [ddnet] bumm ddoser 01:48 <+bridge> [ddnet] <> jk 01:48 <+bridge> [ddnet] bumm ddoser 01:48 <+bridge> [ddnet] :monkaS: 01:49 <+bridge> [ddnet] <> :justatest: 01:49 <+bridge> [ddnet] but i wouldnt be surprised if someone tried 01:49 <+bridge> [ddnet] <> someone haha :justatest: 01:49 <+bridge> [ddnet] someone aka u 01:49 <+bridge> [ddnet] <> no u 01:49 <+bridge> [ddnet] why me 01:49 <+bridge> [ddnet] lol 01:49 <+bridge> [ddnet] <> cuz u are the biggest troll 01:50 <+bridge> [ddnet] ddosing isnt trolling its just being an ass 01:50 <+bridge> [ddnet] also no im not, no u 01:50 <+bridge> [ddnet] thats what a troll would say 05:41 <+bridge> [ddnet] @Aoe 08:25 <+bridge> [ddnet] @noby well highdpi effectively multiplies the resolution maybe the computer is genuinely having trouble getting out all the pixels 08:26 <+bridge> [ddnet] Does it atleast look sharper? 08:26 <+bridge> [ddnet] ddnet 13.0 error 08:26 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/696969099208818758/unknown.png 08:26 <+bridge> [ddnet] a lot of players got this 08:26 <+bridge> [ddnet] help 08:27 <+bridge> [ddnet] @deen ^^ did you forget to ship sth? 08:33 <+bridge> [ddnet] I would take a look but I dont have anything with windows on it 08:38 <+bridge> [ddnet] DDNet 13.0 error message . 08:38 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/696972025008226324/unknown.png 08:39 <+bridge> [ddnet] Title: entry point not found 08:39 <+bridge> [ddnet] Text: entry point to procedure Crypt... not found in dll library. 08:40 <+bridge> [ddnet] @filodex fixed, sorry about that 08:41 <+bridge> [ddnet] How did that happen? Missing libcurl.dll or sth? 08:41 <+bridge> [ddnet] yes, forgot to update libcurl.dll 08:45 <+bridge> [ddnet] Wow, so fast, Thanks! 09:07 <+bridge> [ddnet] @deen I am also getting the same error popup after updating to 13.0 09:07 <+bridge> [ddnet] I have redownloaded 13.0 twice from the webpage, but still the same thing. 09:08 <+bridge> [ddnet] ok, that's too bad 09:08 <+bridge> [ddnet] I hoped that was the fix 😄 09:10 <+bridge> [ddnet] Well, its not like its rushed or anything, I can just redownload 12.9.2 again while waiting. I was also hoping its just the libcurl.dll 09:14 <+bridge> [ddnet] It's weird that it works for me in Wine 09:15 <+bridge> [ddnet] Could be win10 version or a recent update? 09:15 <+bridge> [ddnet] to windows I mean 09:33 <+bridge> [ddnet] Well that function is deprecated but 12.9.2 works, so it can't be removed yet 09:33 <+bridge> [ddnet] I don't think microsoft does macOS like compatibility hooks checking which version a program is linked on 09:34 <+bridge> [ddnet] @deen how do we get curl for windows? just a download or do we compile that aswell? 09:34 <+bridge> [ddnet] compile myself 09:34 <+bridge> [ddnet] but I guess this has nothing to do with curl 09:34 <+bridge> [ddnet] we use CryptAcquireContext in system.c 09:35 <+bridge> [ddnet] My guess would be a mingw change and I might now have to statically link in advapi32.a 09:35 <+bridge> [ddnet] can you even statically link that? it's part of winapi 09:38 <+bridge> [ddnet] not sure, but the error message seems to say that we're missing that symbol in DDNet.exe, right? 09:39 <+bridge> [ddnet] yep 09:40 <+bridge> [ddnet] @deen does mingw come with dumpbin? 09:41 <+bridge> [ddnet] I think it has something similar, maybe you can check with that whether it links with advapi to begin with 09:45 <+bridge> [ddnet] maybe we are missing a linker flag for it? `-ladvapi` is something we could try (not sure why it worked in the past in that case though) 09:46 <+bridge> [ddnet] @onby can you profile that btw? Instruments is a pretty decent profiler, it'd be nice to see where the CPU is spending much more time 09:49 <+bridge> [ddnet] So maybe it's not our fault but SDL2 is doing something wrong 09:50 <+bridge> [ddnet] in 12.9.2 I see CryptAcquireContextA only imported from ADVAPI32.dll 09:50 <+bridge> [ddnet] but in 13.0 it's also imported from SDL2.dll 09:50 <+bridge> [ddnet] yeah, or it's also possible that the cpu is actually used more for the extra pixels, the fan curve on macbooks are VERY steep 09:50 <+bridge> [ddnet] oh you mean that 😄 09:51 <+bridge> [ddnet] huh, SDL2.dll is exporting CryptAcquireContextA? 09:51 <+bridge> [ddnet] we could also disable hidpi mode somehow maybe? 09:52 <+bridge> [ddnet] @deen can you dumpbin sdl2.dll aswell, see if it exports that? 09:52 <+bridge> [ddnet] it's also possible that minGW is just tripping balls 09:52 <+bridge> [ddnet] objdump -x seems to tell me so: https://ddnet.tw/13.0.objdump https://ddnet.tw/12.9.2.objdump 09:53 <+bridge> [ddnet] it's a bit annoying that I can't repro in wine 09:55 <+bridge> [ddnet] somehow I can't check exported symbols, only imported ones 09:55 <+bridge> [ddnet] well if sdl2.dll doesn't even export the symbol it's a problem in mingw 09:55 <+bridge> [ddnet] eh, that's a setback :/ 09:57 <+bridge> [ddnet] maybe you can't objdump libraries not created by mingw 09:57 <+bridge> [ddnet] ah, winedump works, CryptAcquireContextA is not exported in SDL2.dll 09:58 <+bridge> [ddnet] I wonder why mingws linker thinks it does 09:59 <+bridge> [ddnet] i dont get double export when i compile with mingw 09:59 <+bridge> [ddnet] using objdump 09:59 <+bridge> [ddnet] but are you also cross compiling @Jupstar ✪ 09:59 <+bridge> [ddnet] yes 09:59 <+bridge> [ddnet] what version? maybe I upgraded mingw recently and got a weird update 09:59 <+bridge> [ddnet] debian bullseye 10:00 <+bridge> [ddnet] need to lookup the verison 10:00 <+bridge> [ddnet] I verified with winedump and CryütAcquireContextA & CryptGenRandom are imported from SDL2.dll indeed 10:00 <+bridge> [ddnet] we really should finish up that docker container to compile all this 10:00 <+bridge> [ddnet] 9.3.0-8+22 10:00 <+bridge> [ddnet] my bet is that we are running into a linking bug, because the thunks have the same locations 10:00 <+bridge> [ddnet] so basically the import table for SDL2 and ADVAPI32 overlap 10:01 <+bridge> [ddnet] I guess I should try downgrading mingw and opening a bug 10:08 <+bridge> [ddnet] hopefully a downgrade takes care of it 10:26 <+bridge> [ddnet] @deen are you not using https://github.com/ddnet/ddnet-scripts/blob/master/ddnet-release.sh 10:26 <+bridge> [ddnet] to create the binary? 10:27 <+bridge> [ddnet] I am 10:27 <+bridge> [ddnet] ok 10:27 <+bridge> [ddnet] bcs i build another projects wich adds more aggressive compiler optimizations and i get the double symbol there too 10:28 <+bridge> [ddnet] but when i use that script i dont xd 10:28 <+bridge> [ddnet] hm, weird... 10:32 <+bridge> [ddnet] ok not reltaed to that, but still strange 10:33 <+bridge> [ddnet] are you stripping after the script? 10:33 <+bridge> [ddnet] oh yeah 10:33 <+bridge> [ddnet] or doesn't the script 10:33 <+bridge> [ddnet] i think the script does 10:36 <+bridge> [ddnet] oh yeah its in the cmake txt 😄 10:36 <+bridge> [ddnet] ok, do you think that might be the problem? 10:37 <+bridge> [ddnet] i don't think so, but our linker build differently appearently 10:37 <+bridge> [ddnet] so maybe ur right with linker bug, but i also get the double symbol in another project 10:37 <+bridge> [ddnet] and the other project still works fine? 10:37 <+bridge> [ddnet] I also don't get why it works fine in wine, but no on real windows 10:37 <+bridge> [ddnet] i tested it around a week ago and it worked then 10:37 <+bridge> [ddnet] but i can also just go into windows and check 10:39 <+bridge> [ddnet] well it is quite possible that wine is doing some magic to hook that call to CryptAcquireContextA which fixes the issue 10:45 <+bridge> [ddnet] well i get the error in the other project indeed, but not if not stripped 10:45 <+bridge> [ddnet] then I'll just try not stripping 10:45 <+bridge> [ddnet] and i use -s and hide debug symbols in the other project 10:45 <+bridge> [ddnet] u can build and and send it to me @deen 10:45 <+bridge> [ddnet] i can test it 10:46 <+bridge> [ddnet] how much fat does stripping trim anyway? 10:46 <+bridge> [ddnet] alot 10:46 <+bridge> [ddnet] yea 10:47 <+bridge> [ddnet] ok, the non-stripped one still has CryptAcquireContextA imported from SDL2, but not overlapped now 10:47 <+bridge> [ddnet] this leads me to believe that the overlap is an intentional optimization by strip 10:48 <+bridge> [ddnet] oh looks like i have another cmake warning to look into ```cmake 10:48 <+bridge> [ddnet] CMake Warning (dev) at /usr/share/cmake-3.17/Modules/FindPackageHandleStandardArgs.cmake:272 (message): 10:48 <+bridge> [ddnet] The package name passed to `find_package_handle_standard_args` (FFMPEG) 10:48 <+bridge> [ddnet] does not match the name of the calling package (FFmpeg). This can lead to 10:48 <+bridge> [ddnet] problems in calling code that expects `find_package` result variables 10:48 <+bridge> [ddnet] (e.g., `_FOUND`) to follow a certain pattern. 10:48 <+bridge> [ddnet] Call Stack (most recent call first): 10:48 <+bridge> [ddnet] cmake/FindFFmpeg.cmake:82 (find_package_handle_standard_args) 10:48 <+bridge> [ddnet] CMakeLists.txt:332 (find_package) 10:48 <+bridge> [ddnet] This warning is for project developers. Use -Wno-dev to suppress it. 10:48 <+bridge> [ddnet] ``` 10:48 <+bridge> [ddnet] also this 10:48 <+bridge> [ddnet] Can't set BUILD_RPATH in CMake before 3.8, pass -Wl,-rpath,'$ORIGIN' manually if you wish to emulate this. Or just install a newer version of CMake... 10:48 <+bridge> [ddnet] and i have cmake 3.17 xD 10:48 <+bridge> [ddnet] i fixed that already 10:48 <+bridge> [ddnet] both? 10:48 <+bridge> [ddnet] i see 10:48 <+bridge> [ddnet] only the FFMPEG 10:48 <+bridge> [ddnet] ah 10:49 <+bridge> [ddnet] hmm i dont get it now 10:50 <+bridge> [ddnet] (i got that stuff when compiling the aur package) 10:51 <+bridge> [ddnet] btw i found a cool thing, if you use make typing just "make -j" without specifying any core number uses the max number of cores 10:51 <+bridge> [ddnet] ok, wihtout strip it crashes for me in wine too when loading dlls 10:51 <+bridge> [ddnet] @Ryozuki no it does not 😄 10:51 <+bridge> [ddnet] rly? 10:51 <+bridge> [ddnet] well i used a non stripped and it didnt crash 10:51 <+bridge> [ddnet] that builds with maximum parallelization, so it will run as many processes as possible 10:51 <+bridge> [ddnet] (compiled by me) 10:51 <+bridge> [ddnet] If you have a small project it's usually fine, but on a large process this will kill your system and go OOM 10:51 <+bridge> [ddnet] large project* 10:51 <+bridge> [ddnet] ooo 10:52 <+bridge> [ddnet] xd 10:52 <+bridge> [ddnet] @deen are u using mingw posix? 10:52 <+bridge> [ddnet] i saw a project suggesting it in the readme xD 10:52 <+bridge> [ddnet] I'm using mingw-w64 10:52 <+bridge> [ddnet] ok i think i have posix default, dunno if the runtime can make a difference 10:53 <+bridge> [ddnet] atleast regarding the crash 10:53 <+bridge> [ddnet] the other thing is regarding stripping 😄 10:54 <+bridge> [ddnet] why does it even think SDL2 exports that symbol, maybe it's a malformed import table 10:55 <+bridge> [ddnet] well it creates the same export address 10:55 <+bridge> [ddnet] and in my project its not sdl 10:55 <+bridge> [ddnet] its some weird strip bug 10:55 <+bridge> [ddnet] i wonder if -s flag for mingw uses the linux internal strip 10:57 <+bridge> [ddnet] https://github.com/ddnet/ddnet/issues/2114 10:57 <+bridge> [ddnet] :tee_thinking: 10:59 <+bridge> [ddnet] well @deen said it crashes without the strip too 10:59 <+bridge> [ddnet] but thats something different 10:59 <+bridge> [ddnet] for me it works when i compile it 11:00 <+bridge> [ddnet] does it have the double import? 11:00 <+bridge> [ddnet] btw strip -s DDNet.exe does not remove 11:00 <+bridge> [ddnet] 11:00 <+bridge> [ddnet] symbols stripped 11:00 <+bridge> [ddnet] 11:00 <+bridge> [ddnet] debugging information removed 11:00 <+bridge> [ddnet] 11:00 <+bridge> [ddnet] for me, strangly enough 11:00 <+bridge> [ddnet] but the script uses the linux command doesnt it? 11:03 <+bridge> [ddnet] @deen does it crash for u in debug mode? 11:11 <+bridge> [ddnet] binutils source is a little too huge to dissect for this bug 😛 11:12 <+bridge> [ddnet] might also be an SDL2 bug, I'll try downgrading SDL2 later 11:15 <+bridge> [ddnet] well as i said i dont have sdl in the other project 11:15 <+bridge> [ddnet] still get the error 11:45 <+bridge> [ddnet] @Jupstar ✪ if you are here can you link verbosely? 11:45 <+bridge> [ddnet] what does that mean? 11:45 <+bridge> [ddnet] pass --verbose to ld 11:45 <+bridge> [ddnet] mh ok 11:48 <+bridge> [ddnet] it should output the linker script which I wanted to take a look at 11:49 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/697020228307255366/message.txt 11:49 <+bridge> [ddnet] dunno if that was passed to ld 11:49 <+bridge> [ddnet] i just added it to cmake linker flags 11:51 <+bridge> [ddnet] doesn't seem it made it's way to LD 11:51 <+bridge> [ddnet] mhh 11:51 <+bridge> [ddnet] it made it to gcc though 11:51 <+bridge> [ddnet] how did you add to linker flags btw? 11:52 <+bridge> [ddnet] ok i pass it to release maybe it gets overwritten 11:52 <+bridge> [ddnet] looks better now xd 11:52 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/697021055453233162/message.txt 11:53 <+bridge> [ddnet] but looks same to me 11:53 <+bridge> [ddnet] but it only is verbose when its linking 11:53 <+bridge> [ddnet] so that is mingws linker output 11:54 <+bridge> [ddnet] that's gccs --verbose output 11:54 <+bridge> [ddnet] not ld's 11:54 <+bridge> [ddnet] set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} --verbose") 11:54 <+bridge> [ddnet] what am i doing wrong then 11:55 <+bridge> [ddnet] hm, maybe try -Wl,--verbose 11:56 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/697021898046832730/message.txt 11:56 <+bridge> [ddnet] yeah thats verbose xd 11:56 <+bridge> [ddnet] let's see if there is any glaring issue 😛 11:56 <+bridge> [ddnet] fixing an actual binutils bug is a little beyond me 11:58 <+bridge> [ddnet] but i can just tell to clearify: 11:58 <+bridge> [ddnet] i use another project and have the acquire error there too(it uses -s flag which just strips too). 11:58 <+bridge> [ddnet] i don't get any error when i use either my exe or deens exe without stripping 11:58 <+bridge> [ddnet] but deens crashes, mine does not 11:59 <+bridge> [ddnet] can you dump that exe see if it still has the double import 12:00 <+bridge> [ddnet] it does not, but it also does not strip correctly when i use strip -s DDNet.exe, i'll try with -s gimme a minute 12:02 <+bridge> [ddnet] it does not double it 12:02 <+bridge> [ddnet] but in my other project it does xD 12:03 <+bridge> [ddnet] its just random 12:03 <+bridge> [ddnet] are you stripping with binutils strip btw? 12:03 <+bridge> [ddnet] from mingw? 12:03 <+bridge> [ddnet] it should be included in mingw yeah 12:04 <+bridge> [ddnet] well i used linux internal command and -s 12:04 <+bridge> [ddnet] i dunno if i have a mingwstrip 12:04 <+bridge> [ddnet] but according to cmakelist.txt it also just does strip -s 12:05 <+bridge> [ddnet] there is one in bintools and mingw does come with the entire bintools 12:05 <+bridge> [ddnet] what is the cross compiler called? 12:06 <+bridge> [ddnet] try /usr/bin/x86_64-w64-mingw32-strip 12:06 <+bridge> [ddnet] well i use mingw64 12:08 <+bridge> [ddnet] ok used the mingw strip and it stripped, but no double symbol 12:08 <+bridge> [ddnet] but that doesnt mean its working 12:08 <+bridge> [ddnet] i'll try it in windows now, if it doesnt work, it might be related to windows 12:10 <+bridge> [ddnet] The PE executable format is extremely finicky from what I can see from that linker script and the dozens of workarounds in ld's source 12:10 <+bridge> [ddnet] it is entirely possible that stripping with a different version of binutils or one that might be missing the mingw plugin could cause issues 12:12 <+bridge> [ddnet] yeah for me all versions work: 12:12 <+bridge> [ddnet] no strip 12:12 <+bridge> [ddnet] strip with linux strip 12:12 <+bridge> [ddnet] strip with mingw strip 12:12 <+bridge> [ddnet] and in my other project it does not 12:12 <+bridge> [ddnet] doing nothing else xd 12:13 <+bridge> [ddnet] I guess it is indeed a mingw/binutils issue, the best we can do is create an issue about it 12:13 <+bridge> [ddnet] well the question is does mingw -s use mingw strip or linux strip 12:14 <+bridge> [ddnet] mingw -s? 12:14 <+bridge> [ddnet] compiler flag 12:14 <+bridge> [ddnet] you can pass -s to the compiler too? 12:14 <+bridge> [ddnet] yes 12:14 <+bridge> [ddnet] bcs in the other project it uses -s, maybe deens strip does what mingw's -s does too 12:14 <+bridge> [ddnet] or its random 12:14 <+bridge> [ddnet] xD 12:15 <+bridge> [ddnet] maybe deen should use mingw's strip 12:15 <+bridge> [ddnet] but deens version without stripping worked, except it crashes 12:15 <+bridge> [ddnet] he can try but I doubt that's the issue, even without stripping it was broken 12:15 <+bridge> [ddnet] but not bcs no ddl entry was missing 12:15 <+bridge> [ddnet] why must microsoft make everything so hard for everyone? 12:16 <+bridge> [ddnet] maybe they had a bug or changed it, and mingws wrapper call breaks it currently or smth 12:16 <+bridge> [ddnet] like there is no fall back 12:17 <+bridge> [ddnet] but its too strange that the symbol is double tho 12:17 <+bridge> [ddnet] its pure random 12:18 <+bridge> [ddnet] i also don't find any issue regarding this, but the fact that 2 completly different projects have the same error 12:18 <+bridge> [ddnet] makes me wonder nobody reportet it 12:18 <+bridge> [ddnet] It'd be nice if we could all agree on an executable format, ELF is nice and it can even be extended 12:19 <+bridge> [ddnet] @Jupstar ✪ It probably triggers in pretty specific circumstances 12:20 <+bridge> [ddnet] I saw one more person ask about it on stackoverflow but no one could reply 12:20 <+bridge> [ddnet] well atleast u found smth xd 12:20 <+bridge> [ddnet] https://stackoverflow.com/questions/41885215/dependencies-to-cryptreleasecontext-and-other-advapi32-calls-with-cgo 12:21 <+bridge> [ddnet] This guy seems to have very meh english and doesn't describe the issue well, but there it is advapi functions ending up in different/wrong dlls 12:26 <+bridge> [ddnet] I don't even know if we can write a minimal testcase for this while reporting tbh 12:27 <+bridge> [ddnet] well anyway the other project doesnt work at all without or with strip. 12:27 <+bridge> [ddnet] so you really just have to report its not reproducable 12:28 <+bridge> [ddnet] well except you use the excat versions of deens arch linux and the current ddnet github maybe 12:41 <+bridge> [ddnet] okay I give up, PE is just too complex for my mortal eyes 12:42 <+bridge> [ddnet] also I ran out of music 13:04 <+bridge> [ddnet] its probably about this 13:04 <+bridge> [ddnet] http://mingw.org/wiki/MixingCompilers 13:04 <+bridge> [ddnet] 13:04 <+bridge> [ddnet] i tried changing the linkers to mingw-ld without success 13:04 <+bridge> [ddnet] so I should build SDL2 myself? 13:04 <+bridge> [ddnet] well i dunno 13:04 <+bridge> [ddnet] test it out i have 0 plan xD 13:05 <+bridge> [ddnet] to me this sounds like an unrelated issue 13:05 <+bridge> [ddnet] but i remember i build the libs for my project too a longer time ago, so maybe thats it 13:06 <+bridge> [ddnet] i'll try it out for my project and give u feedback 13:09 <+bridge> [ddnet] @deen it indeed worked now 13:09 <+bridge> [ddnet] so yes 13:09 <+bridge> [ddnet] u need to build sdl for mingw yourself XD 13:10 <+bridge> [ddnet] will probs work 13:10 <+bridge> [ddnet] meh 13:10 <+bridge> [ddnet] ah, sdl2 also provides development libs for mingw 13:11 <+bridge> [ddnet] i always used the VS ones I think? 13:11 <+bridge> [ddnet] yeah i think ddnet uses vs ones 13:12 <+bridge> [ddnet] that's the other problem, if I provide mingw ones, then maybe we get other problems when someone builds in visual studio 13:12 <+bridge> [ddnet] so we need both? 13:12 <+bridge> [ddnet] probably the best way 13:12 <+bridge> [ddnet] @heinrich5991 does adding 13:12 <+bridge> [ddnet] set(CMAKE_LINKER x86_64-w64-mingw32-ld) 13:12 <+bridge> [ddnet] set(CMAKE_AR x86_64-w64-mingw32-gcc-ar) 13:13 <+bridge> [ddnet] set(CMAKE_RANLIB x86_64-w64-mingw32-gcc-ranlib) 13:13 <+bridge> [ddnet] to the mingw toolchain makes sense? 13:24 <+bridge> [ddnet] @deen would this commit help? https://github.com/heinrich5991/ddnet/commit/293e58c932e6ffeb779f07e5b0e44fdfe1a849d8 13:25 <+bridge> [ddnet] I don't know. I can try 13:30 <+bridge> [ddnet] ``` 13:30 <+bridge> [ddnet] /usr/lib/gcc/x86_64-w64-mingw32/9.3.0/../../../../x86_64-w64-mingw32/bin/ld: CMakeFiles/DDNet.dir/objects.a(system.c.obj):system.c:(.text+0x579e): undefined reference to `RtlGenRandom' 13:30 <+bridge> [ddnet] /usr/lib/gcc/x86_64-w64-mingw32/9.3.0/../../../../x86_64-w64-mingw32/bin/ld: CMakeFiles/DDNet.dir/objects.a(system.c.obj):system.c:(.text+0x5878): undefined reference to `RtlGenRandom' 13:30 <+bridge> [ddnet] /usr/lib/gcc/x86_64-w64-mingw32/9.3.0/../../../../x86_64-w64-mingw32/bin/ld: CMakeFiles/DDNet.dir/objects.a(system.c.obj):system.c:(.text+0x58e2): undefined reference to `RtlGenRandom' 13:30 <+bridge> [ddnet] ``` 13:34 <+bridge> [ddnet] interesting. I don't get the error locally 😦 13:35 <+bridge> [ddnet] @deen can you try again? I pushed another version 13:40 <+bridge> [ddnet] @heinrich5991 works for me in wine 13:41 <+bridge> [ddnet] sent exe to Jupstar for windows verification 13:53 <+bridge> [ddnet] in the struct `CSwitchTile` from `mapitems.h` 13:53 <+bridge> [ddnet] ``` 13:53 <+bridge> [ddnet] class CSwitchTile 13:53 <+bridge> [ddnet] { 13:53 <+bridge> [ddnet] public: 13:53 <+bridge> [ddnet] unsigned char m_Number; 13:53 <+bridge> [ddnet] unsigned char m_Type; 13:53 <+bridge> [ddnet] unsigned char m_Flags; 13:53 <+bridge> [ddnet] unsigned char m_Delay; 13:53 <+bridge> [ddnet] }; 13:53 <+bridge> [ddnet] ``` 13:53 <+bridge> [ddnet] where can i find what `m_Flags` contains? 13:54 <+bridge> [ddnet] search how its used 13:54 <+bridge> [ddnet] didnt find anything in reasonable time 13:54 <+bridge> [ddnet] so i figured someone here might either know it or find it a lot faster 13:56 <+bridge> [ddnet] it *looks like* they're the normal tile flags 13:57 <+bridge> [ddnet] i.e. rotation, mirroring 13:57 <+bridge> [ddnet] 👍 thx 14:14 <+bridge> [ddnet] so for Jupstar it crashes, not sure why 14:26 <+bridge> [ddnet] @heinrich5991 any hint for how to best use these paths? 14:48 <+bridge> [ddnet] @deen add them to the `set_extra_dirs_lib` function 14:48 <+bridge> [ddnet] in `CMakeLists.txt` 14:52 <+bridge> [ddnet] ``` 14:52 <+bridge> [ddnet] if(TARGET_BITS AND TARGET_OS) 14:52 <+bridge> [ddnet] set(DIR "ddnet-libs/${NAME}/${TARGET_OS}/lib${TARGET_BITS}") 14:52 <+bridge> [ddnet] if(TARGET_OS STREQUAL) 14:52 <+bridge> [ddnet] if(MSVC) 14:52 <+bridge> [ddnet] list(APPEND DIR "ddnet-libs/${TARGET_OS}/lib${TARGET_BITS}/vc") 14:52 <+bridge> [ddnet] else() 14:52 <+bridge> [ddnet] list(APPEND DIR "ddnet-libs/${TARGET_OS}/lib${TARGET_BITS}/mingw") 14:52 <+bridge> [ddnet] endif() 14:52 <+bridge> [ddnet] endif() 14:52 <+bridge> [ddnet] [...] 14:53 <+bridge> [ddnet] endif() 14:53 <+bridge> [ddnet] ``` 14:53 <+bridge> [ddnet] @deen ^ 14:53 <+bridge> [ddnet] btw, the libsdl.org sdl2.dll for mingw also didn't fix the issue, so now I'm building my own 14:53 <+bridge> [ddnet] thanks 14:55 <+bridge> [ddnet] ``` 14:55 <+bridge> [ddnet] if(TARGET_BITS AND TARGET_OS) 14:55 <+bridge> [ddnet] set(DIR "ddnet-libs/${NAME}/${TARGET_OS}/lib${TARGET_BITS}") 14:55 <+bridge> [ddnet] if(TARGET_OS STREQUAL "windows") 14:55 <+bridge> [ddnet] if(MSVC) 14:55 <+bridge> [ddnet] list(APPEND DIR "ddnet-libs/${TARGET_OS}/lib${TARGET_BITS}/vc") 14:55 <+bridge> [ddnet] else() 14:55 <+bridge> [ddnet] list(APPEND DIR "ddnet-libs/${TARGET_OS}/lib${TARGET_BITS}/mingw") 14:55 <+bridge> [ddnet] endif() 14:55 <+bridge> [ddnet] endif() 14:55 <+bridge> [ddnet] [...] 14:55 <+bridge> [ddnet] endif() 14:55 <+bridge> [ddnet] ``` 15:18 <+bridge> [ddnet] @deen do you understand this error? 15:18 <+bridge> [ddnet] ``` 15:18 <+bridge> [ddnet]