This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Embedded targets problem
Dmitry wrote:
>
> > > It looks like new 'gcov' stuff breaks embedded targets builds.
> > > This is probably cause gcov refers to some includes such as 'stdio.h' and
> > > 'fcntl.h' which not always exist for small machines.
> >
> > This shouldn't break any embedded target which either uses newlib and
> > is configured --with-newlib or has a modest C library that gcc is made
> Well, my (msp430) target has no newlib and this (--with-newlib) configure
> option does not help much. And yes, we have some sort of libc which obviously
> cannot be compiled without a cross gcc buld.
newlib is not the only option for building cross compilers.
You can use an existing prebuilt C library when building gcc
as well. This is the procedure you have to use when building
a cross to a target which has a proprietary C library such
as Solaris.
Before you build the cross gcc, put the header files for your
C library in ${prefix}/${target}/sys-include and the
libraries under ${prefix}/${prefix}/lib. gcc should find them
as part of the build then.
> > aware via the proper configure options. Are you trying to build with
> > no references to the C library at all?
> Yes, I am trying to build cross gcc and cross compile 'libgcc2.c' without any
> target-specific library installed
If these can be built with your target's library, then just preinstall
it.
Or... effectively do what --with-newlib does. Let it turn on a path
to your target's C library so that gcc knows where the include files
are in the source tree. If you integrate this way, then you would have
to make your C library part of the top level build procedure. But it
should just be a matter of adapting what was done with newlib.
> I think the problem comes from Makefile.in where
> LIB2FUNCS_ST = _eprintf _gcov __gcc_bcmp
>
> defined and cannot be overriden by any config options.
>
> Is it possible yo apply a small patch which will fix this problem?
If this is all you want to do, why not define inhibit_libc in your
target's
config/t-XXX file? I think it does exactly what you want to do.
> [2003-01-03] whoever
> * Makefile.in (LIB2FUNCS_ST): define this only in case
> 'config/target/t-target' has not defined LIB2FUNCS_ST allowing small machines
> avoid building unsupported functions.
>
> Index: Makefile.in
> ===================================================================
> RCS file: /cvsroot/gcc/gcc/gcc/Makefile.in,v
> retrieving revision 1.963
> diff -c -3 -p -r1.963 Makefile.in
> *** Makefile.in 7 Jan 2003 17:05:05 -0000 1.963
> --- Makefile.in 9 Jan 2003 08:15:28 -0000
> *************** LIB2FUNCS_2 = _floatdixf _fixunsxfsi _fi
> *** 799,805 ****
> _addvdi3 _subvsi3 _subvdi3 _mulvsi3 _mulvdi3 _negvsi2 _negvdi2 _ctors
>
> # Defined in libgcc2.c, included only in the static library.
> ! LIB2FUNCS_ST = _eprintf _gcov __gcc_bcmp
>
> FPBIT_FUNCS = _pack_sf _unpack_sf _addsub_sf _mul_sf _div_sf \
> _fpcmp_parts_sf _compare_sf _eq_sf _ne_sf _gt_sf _ge_sf \
> --- 799,805 ----
> _addvdi3 _subvsi3 _subvdi3 _mulvsi3 _mulvdi3 _negvsi2 _negvdi2 _ctors
>
> # Defined in libgcc2.c, included only in the static library.
> ! LIB2FUNCS_ST?= _eprintf _gcov __gcc_bcmp
>
> FPBIT_FUNCS = _pack_sf _unpack_sf _addsub_sf _mul_sf _div_sf \
> _fpcmp_parts_sf _compare_sf _eq_sf _ne_sf _gt_sf _ge_sf \
--
Joel Sherrill, Ph.D. Director of Research & Development
joel@OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985