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: Build break on SPU (and other non-mmap systems?) (Re: [patch,libgfortran,toplevel] Use libbacktrace in libgfortran)


FX Coudert wrote:

> The idea is that libbacktrace should be able to build on all targets, at
> least in a minimally-functional form:
> https://gcc.gnu.org/ml/gcc/2015-08/msg00038.html
> libgfortran should continue to build on all targets, even those that
> don't have an mmap().
> 
> I see that there is a test in libbacktrace/configure.ac for mmap(), but
> apparently it fails on your system:

Ah, I see.  On the SPU, we do have an sys/mman.h header file, which provides
a "mmap_eaddr" routine used to map files into the DMA address space, and
associated mmap flags.  That's why the test gets confused.

> So this should be the place to patch things up. Relying on the presence of
> <sys/mman.h> is apparently not restrictive enough. Maybe we could use a
> AC_EGREP_HEADER test, as is currently done for dl_interate_phdr()?

Hmm, that seems tricky, since the SPU sys/mman.h file contains the prototype
for mmap_eaddr, and the string "mmap" in various comments ...

I guess we can always just hard-code that SPU does not have mmap, similar
to how Solaris is hard-coded to not have dl_iterate_phdr.

Would something like the below be OK (if it passes testing)?

Thanks,
Ulrich


Index: libbacktrace/configure.ac
===================================================================
--- libbacktrace/configure.ac	(revision 227056)
+++ libbacktrace/configure.ac	(working copy)
@@ -273,6 +273,12 @@ else
     # When built as a GCC target library, we can't do a link test.  We
     # simply assume that if we have mman.h, we have mmap.
     have_mmap=yes
+    case "${host}" in
+    spu-*-*)
+        # The SPU does not have mmap, but it has a sys/mman.h header file
+        # containing "mmap_eaddr" and the mmap flags, confusing the test.
+	have_mmap=no ;;
+    esac
   else
     AC_CHECK_FUNC(mmap, [have_mmap=yes], [have_mmap=no])
   fi


-- 
  Dr. Ulrich Weigand
  GNU/Linux compilers and toolchain
  Ulrich.Weigand@de.ibm.com


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