https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126839
--- Comment #3 from Hans-Peter Nilsson <hp at gcc dot gnu.org> --- (In reply to Iain Sandoe from comment #1) > Sorry for the breakage - but likewise it is not obvious to me (GNU runtime > builds and runs on both ELF and Mach-O hosted systems). Totally understandable, but if you could include a bare-iron cross-target a part of your regular testing procedure, that would be great. (I can't help you except with cris-elf and pru-elf though, haven't succeeded building and testing for others in a while.) > Please could you post the configuration info and the version of binutils > needed to repeat this). binutils: ce67ec902d83 git://sourceware.org/git/binutils-gdb.git sim: same as binutils newlib: Both cris-elf and pru-elf have newlib bc8ccf313033 (right before an initfini breaking change for cris-elf that is now reverted) git://sourceware.org/git/newlib-cygwin.git. The exact version of newlib (besides the initfini breakage) is not key here as I observed the problem with a much earlier newlib for cris-elf. If you have ever build and tested a bare-iron embedded simulator-based target, then the following is largely redundant information and you may have your own go-to procedure: Configure and build binutils and sim with an appropriate --prefix and respectively --target=cris-elf and --target=pru-elf for two separate builds. Combine newlib with gcc. Copy (untar, rsync, perhaps symlink) gcc sources over newlib at the toplevel, to make gcc override differences. Then configure each target for yet two other builds with an appropriate --prefix and with PATH appended with the earlier <PREFIX>/bin and with the same --target=cris-elf and --target=pru-elf parameters. Build with "make all", then "make check-objc RUNTESTFLAGS=--target_board=X-sim", for X=(pru,cris), with any semi-recent dejagnu, such as dejagnu-1.6.3. For gcc versions after the breaking commit you should now observe the FAILs. > I don't think that there's anything in the metadata > generation that should depend on hosted/bare metal -- but there could be > things that depend on the linker in use .. Presumably, libobjc is linked > statically; that could be completely untested on hosted systems. Right, static linking may be key here. Still, I don't know what in your commit could possibly break that, that doesn't break for dynamic linking. Wild guess: something is ordered differently that worked by chance before? I guess attribute init_priority would then be the rescue. > That is the clue, I suppose, but I'll likely need to side-by-side the > metadata to figure out what has changed (nothing was supposed to have > changed - this was 'just' making sure the meta data constructors had > properly typed elements). Thank you for the quick response!
