On 22/12/17 7:09 pm, Sebastian Huber wrote: > On 21/12/17 08:15, Chris Johns wrote: >> On 21/12/17 5:47 pm, Sebastian Huber wrote: >>> Hello, >>> >>> we should try to understand better why the things are how they are >>> currently. >> Agreed. >> >>> In Newlib we have this ctr0.c: >>> >>> https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=newlib/libc/sys/rtems/crt0.c;h=9778b985a180ba68990b40b6e4423aa970ca5ec7;hb=HEAD >>> >>> >>> >>> This is the default start file for the RTEMS GCC: >>> >>> https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/config/rtems.h?view=markup >>> >>> /* >>> * Dummy start/end specification to let linker work as >>> * needed by autoconf scripts using this compiler. >>> */ >>> #undef STARTFILE_SPEC >>> #define STARTFILE_SPEC "crt0.o%s" >>> >>> We use the bsp_specs to override this (we could also use -nostartfiles at >>> the >>> command line): >>> >>> %rename startfile old_startfile >>> >>> *startfile: >>> %{!qrtems: %(old_startfile)} \ >>> %{!nostdlib: %{qrtems: crti.o%s crtbegin.o%s}} >>> >>> Why do we define a STARTFILE_SPEC in GCC which we don't use for real >>> applications? >>> >> I good question. The gcc defaults should be focused on a user and the closer >> this is to other platforms the better. >> >>> The purpose of the ctr0.o seems to be to make the Autoconf stuff happy >>> during >>> GCC build, e.g. for libstdc++. >> Do other build system tests, ie autoconf, require an installed BSP? > > If you do link-time checks then we support currently two variants. > > 1. Via the Newlib ctr0.o which promises that a BSP will provide a proper > implementation eventually (using other compiler/linker options).
Could you please provide a little more on detail on how this would work? > > 2. You provide all options to link against the real BSP libraries. > Is "you" a user? > The support for 1. is actually quite nice. You can build libraries per > multilib > with it. I think I see what you are asking but I am missing some of the detail to be certain. > >> >>> One option would be to do this: >>> >>> 1. Change STARTFILE_SPEC: >>> >>> #undef STARTFILE_SPEC >>> #define STARTFILE_SPEC "start.o%s crti.o%s crtbegin.o" >>> >> What does a list mean? > > Several startfiles. We also have endfiles. > >> >>> 2. Rename Newlib ctr0.o into start.o and do NOT install it. This way it is >>> used >>> only during GCC build to make the GCC Autoconf happy. >> OK. >> >>> 3. Provide start.o in all BSPs. >>> >>> How do we deal with other Autoconf (or other link-time feature detection) >>> stuff? >>> This change could break all the third party library build scripts. >> I do not think this can be avoided or we can never change what we have. I do >> not >> like the use of -B on the gcc command line. > > I think the -B switch is the only way to add search paths at the command line > for startfiles, see "add_prefix.*startfile" in gcc/gcc.c. > The -B option has side effects and I now feel after working on no-preinstall we are better off without it. It's ability to search for .o, .a, linkcmds, and bspspecs files makes it difficult to control. I have grown a dislike for it. Yes it works however it is nerdy and complicated and we need to search for a way to remove our dependence on it. Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
