On Wed, Jan 03, 2007 at 11:28:29PM -0500, Daniel Jacobowitz wrote:
I've just committed the approved top level libgcc patches, which
create a top level libgcc directory.
I updated to revision 120997 for my Intel x86 16-bit port, to find:
Checking multilib configuration for libgcc...
Rask Ingemann Lambertsen [EMAIL PROTECTED] writes:
Checking multilib configuration for libgcc...
Configuring in ia16-elf/libgcc
[snip]
checking whether decimal floating point is supported... no
*** Configuration ia16-unknown-elf not supported
make[1]: *** [configure-target-libgcc] Fejl 1
On Wed, Jan 03, 2007 at 11:28:29PM -0500, Daniel Jacobowitz wrote:
Hopefully, this will not have any great impact on much of anyone.
It does. It fixed PR target/30370 (libgcc failing to build on
powerpc-unknown-eabispe) on mainline.
--
Rask Ingemann Lambertsen
On Thu, Jan 04, 2007 at 04:19:17PM +1100, Ben Elliston wrote:
On Wed, 2007-01-03 at 23:28 -0500, Daniel Jacobowitz wrote:
Right now the libgcc configuration is completely tied up with
gcc/Makefile. As parts of the configuration process move from
gcc/config/ to libgcc/config/ (or libgcc's
I've just committed the approved top level libgcc patches, which
create a top level libgcc directory.
Hopefully, this will not have any great impact on much of anyone.
The only change I know of is that if you run make all-gcc, you will
no longer have enough to test C. You need at least make
On Wed, 2007-01-03 at 23:28 -0500, Daniel Jacobowitz wrote:
Right now the libgcc configuration is completely tied up with
gcc/Makefile. As parts of the configuration process move from
gcc/config/ to libgcc/config/ (or libgcc's configure.ac), we'll
be untangling them. Eventually, it should
Ben Elliston wrote:
So I take it that at this stage we've not commenced the process of
having libgcc's configury run autoconf tests on the target compiler?
(Rather than having to hardwire most target details into the t-* files?)
Any objections to starting down this path?
We should also be
We should also be very careful not to introduce differences between
native and cross compilers. So, we should have no run-time tests, no
tests that look at /proc, headers in /usr/include, etc.
Right--I was really only suggesting tests that can be done at
compile-time. Perhaps there isn't a
We should also be very careful not to introduce differences between
native and cross compilers. So, we should have no run-time tests, no
tests that look at /proc, headers in /usr/include, etc.
Right--I was really only suggesting tests that can be done at
compile-time. Perhaps there
Andrew Pinski wrote:
We should also be very careful not to introduce differences between
native and cross compilers. So, we should have no run-time tests, no
tests that look at /proc, headers in /usr/include, etc.
Right--I was really only suggesting tests that can be done at
compile-time.
10 matches
Mail list logo
