This is the mail archive of the gcc-patches@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: 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


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