The Hurd does not currently support the
MREMAP_MAYMOVE case it is easy to work around; see
[binutils]/gold/mremap.c, for example.
Also see the discussion of mmap.
<antrik> maybe it would be easiest actually to implement mremap()?... <braunr> antrik: i'm nto sure <braunr> antrik: implementing mremap could be relatively easy to do actually <braunr> antrik: IIRC, vm_map() supports overlapping <antrik> braunr: yes, I think so too <antrik> braunr: haven't checked, but I have a vague recollection that the fundamentals are pretty much there
<bdefreese> OK, how the heck do you get an undefined reference to mremap? <youpi> simply because we don't have it <pinotree> mremap exists only on linux <bdefreese> It's in sys/mman.h <pinotree> on linux? <bdefreese> No, on GNU/Hurd <bdefreese> /usr/include/i386-gnu/sys/mman.h <youpi> that's just the common file with linux <youpi> containing just the prototype <youpi> that doesn't mean there's an implementation behind <pinotree> youpi: hm no, linux has an own version <youpi> uh <bdefreese> Ah, aye, I didn't look at the implementation.. :( <youpi> it's then odd that it was added to the generic sys/mman.h :) <bdefreese> Just another stub? <pinotree> ah, only few linux archs have own versions <youpi> for the macro values I guess <pinotree> http://paste.debian.net/175173/ on glibc/master <bdefreese> Hmm, so where is MREMAP_MAYMOVE coming in from? <youpi> rgrep on a linux box ;) <youpi> <bits/mman.h> <youpi> but that's again linuxish <bdefreese> Aye but with us having that in the header it is causing some code to be run which utilizes mremap. If that wasn't defined we wouldn't be calling it. <youpi> ah <youpi> we could try to remove it indeed <bdefreese> Should I change the code to #ifdef MREMAP_MAYMOVE & !defined __GNU__? <youpi> no, I said we could remove the definition of MREMAP_MAYMOVE itself