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
