Am Sonntag, den 04.02.2018, 12:18 +0100 schrieb Armin K.:
> On Sun, 2018-02-04 at 11:42 +0100, Thomas Trepl wrote:
> > Hi,
> > 
> > got a abort message when compiling postgresql:
> > 
> > D_GNU_SOURCE   -c -o copy_fetch.o copy_fetch.c
> > copy_fetch.c:159:1: Fehler: In Konflikt stehende Typen für
> > »copy_file_range«
> >  copy_file_range(const char *path, off_t begin, off_t end, bool
> > trunc)
> >  ^~~~~~~~~~~~~~~
> > In file included from copy_fetch.c:15:0:
> > /usr/include/unistd.h:1110:9: Anmerkung: Vorherige Deklaration von
> > »copy_file_range« war hier
> >  ssize_t copy_file_range (int __infd, __off64_t *__pinoff,
> >          ^~~~~~~~~~~~~~~
> > 
> > ...

> > To me it looks like a clash to the standard library function
> > copy_file_range. It's easy to fix as postgresql's copy_file_range
> > is
> > a
> > static function. I did following sed
> > 
> > sed -e "s/copy_file_range/_&/" \
> >     -i src/bin/pg_rewind/copy_fetch.c
> > 
> > with which compilation was successfull. Donno whether it is caused
> > now
> > by gcc-7.3 and/or glibc-2.27 (on i686).
> > 
> > Have you seen that issue, too or is it something wired here
> > locally?
> > 
> > --
> > Thomas
> 
> From what I've seen, glibc-2.27 introduced copy_file_range. You could
> try and swap any instance of copy_file_range in postgresql with, say,
> pg_copy_file_range to avoid conflicts (or try and delete
> copy_file_range in pgsql entirely, and let it use the one from
> glibc).

Yes, now found the statement in glibc's changelog

"* The copy_file_range function was added."

I'll add a small sed to the postgresql instructions as it is quite easy
to fix (and occurs only in one file).

Should I open/fix/close a ticket for that?

--
Thomas
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Reply via email to