| Message ID | 52443AFE.5050802@arm.com |
|---|---|
| State | New |
| Headers | show |
On Thu, 2013-09-26 at 14:47 +0100, Marcus Shawcroft wrote: > I'm in two minds about whether further sticky tape of this form is the > right approach or whether the original patch should be reverted until a > proper fix that does not regress the tree can be found. > > Thoughts? > > 2013-09-26 Marcus Shawcroft <marcus.shawcroft@arm.com> > > * configure.ac (AC_CHECK_FUNCS_ONCE): Make if statement > dependent on gcc_no_link. > > Cheers > /Marcus I think this patch is a good fix. I (obviously) don't favor reverting the previous patch because that would re-break the Fortran build on MIPS bare-metal cross compilers (or any compiler where a linker script is needed). Any 'proper' fix should address libstdc++, libjava, and other libraries as well as libgfortran and I don't know what a cleaner fix would be. In fact I would say the other libraries should consider using this fix. The only reason they don't run into this problem too is that they don't depend on any long double functions or any other functions that are optionally built by newlib. I will test this patch on my targets and make sure it works for me, but I don't see why it would not. Steve Ellcey sellcey@mips.com
On Thu, 2013-09-26 at 14:47 +0100, Marcus Shawcroft wrote: > I'm in two minds about whether further sticky tape of this form is the > right approach or whether the original patch should be reverted until a > proper fix that does not regress the tree can be found. > > Thoughts? > > 2013-09-26 Marcus Shawcroft <marcus.shawcroft@arm.com> > > * configure.ac (AC_CHECK_FUNCS_ONCE): Make if statement > dependent on gcc_no_link. > > Cheers > /Marcus Well, I thought this patch would work for me, but it does not. It looks like gcc_no_link is set to 'no' on my target because, technically, I can link even if I don't use a linker script. I just can't find any functions. % cat x.c int main (void) { return 0; } % mips-mti-elf-gcc x.c -o x /local/home/sellcey/nightly/install-mips-mti-elf/lib/gcc/mips-mti-elf/4.9.0/../../../../mips-mti-elf/bin/ld: warning: cannot find entry symbol __start; defaulting to 0000000000400098 % echo $? 0 % cat y.c int main (void) { exit (0); } % install-mips-mti-elf/bin/mips-mti-elf-gcc y.c -o y /local/home/sellcey/nightly/install-mips-mti-elf/lib/gcc/mips-mti-elf/4.9.0/../../../../mips-mti-elf/bin/ld: warning: cannot find entry symbol __start; defaulting to 0000000000400098 /tmp/ccdG78PN.o: In function `main': y.c:(.text+0x14): undefined reference to `exit' collect2: error: ld returned 1 exit status ubuntu-sellcey % echo $? 1 Steve Ellcey sellcey@mips.com
On 27/09/13 17:08, Steve Ellcey wrote: > On Thu, 2013-09-26 at 14:47 +0100, Marcus Shawcroft wrote: > >> I'm in two minds about whether further sticky tape of this form is the >> right approach or whether the original patch should be reverted until a >> proper fix that does not regress the tree can be found. >> >> Thoughts? >> >> 2013-09-26 Marcus Shawcroft <marcus.shawcroft@arm.com> >> >> * configure.ac (AC_CHECK_FUNCS_ONCE): Make if statement >> dependent on gcc_no_link. >> >> Cheers >> /Marcus > > Well, I thought this patch would work for me, but it does not. It looks > like gcc_no_link is set to 'no' on my target because, technically, I can > link even if I don't use a linker script. I just can't find any > functions. > > > % cat x.c > int main (void) { return 0; } > % mips-mti-elf-gcc x.c -o x > /local/home/sellcey/nightly/install-mips-mti-elf/lib/gcc/mips-mti-elf/4.9.0/../../../../mips-mti-elf/bin/ld: warning: cannot find entry symbol __start; defaulting to 0000000000400098 > % echo $? > 0 > > > % cat y.c > int main (void) { exit (0); } > % install-mips-mti-elf/bin/mips-mti-elf-gcc y.c -o y > /local/home/sellcey/nightly/install-mips-mti-elf/lib/gcc/mips-mti-elf/4.9.0/../../../../mips-mti-elf/bin/ld: warning: cannot find entry symbol __start; defaulting to 0000000000400098 > /tmp/ccdG78PN.o: In function `main': > y.c:(.text+0x14): undefined reference to `exit' > collect2: error: ld returned 1 exit status > ubuntu-sellcey % echo $? > 1 In which case gating on gcc_no_link could be replaced with a test that looks to see if we can link with the library. Perhaps looking for exit() or some such that might reasonably be expected to be present. For example: AC_CHECK_FUNC(exit) if test "x${with_newlib}" = "xyes" -a "x${ac_cv_func_exit}" = "xno"; then /Marcus
diff --git a/libgfortran/configure.ac b/libgfortran/configure.ac index 4609eba..411ab38 100644 --- a/libgfortran/configure.ac +++ b/libgfortran/configure.ac @@ -261,7 +261,7 @@ GCC_HEADER_STDINT(gstdint.h) AC_CHECK_MEMBERS([struct stat.st_blksize, struct stat.st_blocks, struct stat.st_rdev]) # Check for library functions. -if test "x${with_newlib}" = "xyes"; then +if test "x${with_newlib}" = "xyes" -a "x${gcc_no_link}" = "xyes" ; then # We are being configured with a cross compiler. AC_REPLACE_FUNCS # may not work correctly, because the compiler may not be able to # link executables.
This patch: http://gcc.gnu.org/ml/fortran/2013-06/msg00038.html ... breaks libgfortran configure against newlib. The solution implemented hard wires an assumption in libgfortran/configure.ac that newlib provides strtold(). This assumption is not correct, newlib only provides an implementation of strtold on systems where sizeof(long double) == sizeof(double). This manifests as a regression when trying to build a cross aarch64 bare metal toolchain with fortran enabled. The attached patch tightens the condition introduced in the earlier patch such that we continue to call AC_CHECK_FUNCS_ONCE unless we know that link tests are not possible, in which case we fall back to the existing broken assumption. I'm in two minds about whether further sticky tape of this form is the right approach or whether the original patch should be reverted until a proper fix that does not regress the tree can be found. Thoughts? 2013-09-26 Marcus Shawcroft <marcus.shawcroft@arm.com> * configure.ac (AC_CHECK_FUNCS_ONCE): Make if statement dependent on gcc_no_link. Cheers /Marcus