public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Joel Sherrill <joel.sherrill@OARcorp.com>
To: diwil@eis.ru
Cc: gcc@gcc.gnu.org, gcc-patches@gcc.gnu.org
Subject: Re: Embedded targets problem
Date: Thu, 09 Jan 2003 16:32:00 -0000	[thread overview]
Message-ID: <3E1D7EB6.9C069A38@OARcorp.com> (raw)
In-Reply-To: <200301091117.23289.diwil@eis.ru>



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

  reply	other threads:[~2003-01-09 13:53 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-08 16:53 Dmitry
2003-01-08 17:15 ` Joel Sherrill
2003-01-09 13:02   ` Dmitry
2003-01-09 16:32     ` Joel Sherrill [this message]
2003-01-09 16:36       ` Dmitry
2003-01-09 16:38         ` Joel Sherrill
     [not found]           ` <200301091719.40052.diwil@eis.ru>
2003-01-09 16:40             ` Joel Sherrill

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3E1D7EB6.9C069A38@OARcorp.com \
    --to=joel.sherrill@oarcorp.com \
    --cc=diwil@eis.ru \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=gcc@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).