On Tue, 17 Jun 2025, Corinna Vinschen wrote: > On Jun 16 22:12, Jeremy Drake via Cygwin-patches wrote: > > gcc 13.4.0 rebuilt successfully too. The thing to watch out for with this > > is "relocation truncated to fit" link errors. > > I don't see those when building Cygwin. What are you doing differently? > Compiler or binutils version?
This was with an earlier version of the patch that failed to build in CI on Github. https://github.com/jeremyd2019/cygwin/commit/cd822eb2569755e992d8ef94c4a3b4097ed2a36a > > Oddly enough, I saw this > > when using the absolute symbols from the C++ inside the Cygwin DLL build, > > but have not seen it building either DLLs or EXEs using clang or gcc, even > > when trying to recreate the scenario (comparing a pthread_mutex_t to > > PTHREAD_MUTEX_INITIALIZER). > > This may be fallout from using -mcmodel=small, see winsup/cygwin/Makefile.am. > Default is -mcmodel=medium, IIRC. That's probably it. > When we ported Cygwin to x86_64, we got "relocation truncated to fit" > when we decided to move the address space used by Cygwin on 64 bit > beyond the 2 Gigs border. Gcc and binutils got tweaked specificially to > allow Cygwin to use the full address space as desired. But the PTHREAD > macros never triggered this problem before, which is puzzeling. The pthread macros were previously casts of integers to pointers, which would always be full absolute pointers. This change is making them actual symbols which the linker fills in with absolute addresses. This would be out of range of a 32-bit rip-relative relocation in cases where the image base is >4GB. This is really gross, as I said, but was the only way I came up with to make them satisfy constinit's restrictions in clang (and the standard, it seems GCC allows things that are explicitly disallowed by the standard). Somewhat surprising to me is that clang also disallows using the address of a dllimported extern variable in constinit, so we couldn't even dllexport "magic" objects from the DLL whose addresses could be compared against instead of (pthread_mutex_t)19 and such.
