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
next prev parent 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).