This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: [EXTERNAL] Re: How to test aarch64 when building a cross-compiler?



> 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

Thanks, Jeff. qemu did the trick. Specifically, I did the following:

1. sudo apt-get install qemu-user-static
2. export LD_LIBRARY_PATH=${BuildRoot}/install/glibcs/aarch64-linux-gnu/lib64:${BuildRoot}/install/compilers/aarch64-linux-gnu/aarch64-glibc-linux-gnu/lib64 
3. sudo ln -s ${BuildRoot}/install/glibcs/aarch64-linux-gnu/lib/ld-linux-aarch64.so.1 /lib/ld-linux-aarch64.so.1
4. Run the gcc tests as previously described
5. Remove the symlink
6. Restore the previous value of LD_LIBRARY_PATH

There are still a few test failures that we will need to investigate, but this was a huge leap forward.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]