diff mbox

Build break on SPU (and other non-mmap systems?) (Re: [patch,libgfortran,toplevel] Use libbacktrace in libgfortran)

Message ID 20150824125544.56C5E1249E@oc7340732750.ibm.com
State New
Headers show

Commit Message

Ulrich Weigand Aug. 24, 2015, 12:55 p.m. UTC 
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

Comments

FX Coudert Aug. 24, 2015, 1:15 p.m. UTC | #1 
> 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)?

Looks good to me, though I cannot approve it.

FX
Jeff Law Aug. 24, 2015, 5:26 p.m. UTC | #2 
On 08/24/2015 06:55 AM, Ulrich Weigand wrote:
> 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)?
Yes.

Jeff
diff mbox

Patch

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