Christoph Reiter via Cygwin writes: > binutils 2.36 now defaults to ASLR etc on Windows, so a cygwin compiled linker > will give you: > >> peflags -v mydll.dll > mydll.dll: coff(0x2026[+executable_image,+line_nums_stripped,+bigaddr,+dll]) > pe(0x0160[+high-entropy-va,+dynamicbase,+nxcompat]) > > Is this still problematic for cygwin?
Yes it is and I'm currently figuring out how to best get rid of it in order to be able to update binutils (why this was ever allowed in without an accompanying configure option is a mystery to me). I've already nixed it for Cygwin, but I'm not yet sure what to do for the cross compilation toolchain. While it should in principle work there, I'm pretty sure that there will be problems when it comes to the nitty gritty details. It's already transpired that some of the linker scripts can't deal with the larger base addresses this change does generate eventually. > The reason I'm asking is because we updated to 2.36 in MSYS2 and are > wondering if we need to patch this out (or change the defaults) It > seems to work as is right now, but maybe we are just lucky(?). You are just lucky and need to test more. :-) Note that the change does not only affect DLL as the commit message would want you to believe and you will eventually end up with a situation where ASLR tries moves the stack of an executable, at which point you can no longer fork. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation: https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
