https://sourceware.org/bugzilla/show_bug.cgi?id=25803
--- Comment #11 from beatlesnut at mac dot com --- It's interesting the n32 build doesn't have this issue. So it must be something to do with wrapping a 64 bit time type to 32 using mabi=32 I think. Shouldn't, or don't, most 32 bit systems have 64 bit time types? Maybe this is the issue since "o"64 and n32 compile fine, and n32 is simply a 32 bit library on a 64 bit host iirc. Original Message From: Gagan Sidhu Sent: Wednesday, 15 April 2020 10:23 AM To: nickc at redhat dot com Subject: Re: [Bug binutils/25803] cross compilation of glibc using mips64el-none-linux-gnu as the host Hi, I think those are all core functions of the time stuff, yes? I do believe I cannot resolve 64 bit time types with my current build but I haven't double checked. It's possible the compiler wraps the 64 bit time type to 32 and requires static linkage to do so? Not sure, just spitballing here. Original Message From: nickc at redhat dot com Sent: Wednesday, 15 April 2020 10:19 AM To: br...@mac.com Subject: [Bug binutils/25803] cross compilation of glibc using mips64el-none-linux-gnu as the host https://sourceware.org/bugzilla/show_bug.cgi?id=25803 Nick Clifton <nickc at redhat dot com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|DUPLICATE |--- Status|RESOLVED |REOPENED Last reconfirmed| |2020-04-15 Ever confirmed|0 |1 --- Comment #9 from Nick Clifton <nickc at redhat dot com> --- Hi Guys, Thanks for the uploads. There were lots of files missing, but I have been able to work around them and I can now reproduce the failures. I do not yet know the cause of the problem, but it is occurring because the following non-dynamic symbols are being detected in a dynamic symbol table: clock_gettime clock_getcpuclockid clock_getres clock_nanosleep clock_settime Do they ring any bells ? Are they special in some way ? Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
