On 11/25/19 2:43 PM, Andrew Dean via gcc wrote: >>>>>> I get errors like this: >>>>>> >>>>>> aarch64-glibc-linux-gnu-gcc: fatal error: cannot read spec file >>>>>> 'rdimon.specs': No such file or directory >>>>>> >>>>>> I can see that the rdimon.specs flag is added based on this line >>>>>> in aarch64- >>>>> sim.exp: >>>>> >>>>> Where does aarch64-sim.exp comes from? >>>> >>>> /usr/share/dejagnu/baseboards/aarch64-sim.exp >>>> >>>>> >>>>>> >>>>>> set_board_info ldflags "[libgloss_link_flags] [newlib_link_flags] >>>>>> - >>>>> specs=rdimon.specs" >>>>>> >>>>> I think this is for baremetal/newlib targets, ie. aarch64-elf, not >>>>> for aarch64- linux-gnu. >>>> >> >> Yes -specs=rdimon.specs and other such flags are for use only on bare-metal >> targets. >> >>>> Hmm.. build-many-glibcs.py doesn't like either aarch64-elf or >>>> aarch64-linux- >> elf... >>>> I get a KeyError in build_compilers and build_glibcs when it tries to look >>>> up >> the config with either of those values. >>>> >>> >>> Unfortunately the build-many-glibcs.py does not have support for >>> baremetal build yet (since it is a tool created to build >>> cross-compiling toolchain using glibc). >> >> And glibc doesn't work bare-metal ...... >> >> regards >> Ramana > I guess that means that the dejagnu baseboard "aarch64-sim" is only meant to > do bare-metal testing? How would one build/test GCC hosted on x86_64 and > targeting aarch64 then? Is there a different simulator approach I should be > using? I've used qemu for this kind of testing. In my environment I have root filesystems with native binaries/libraries. I can just chroot into those filesystems and qemu handles everything.
In theory one wouldn't even need to chroot into the filesystems if you set the library paths right. jeff
