Re: [blfs-dev] Compile issue postgresql

2018-02-04 Thread Bruce Dubbs

Thomas Trepl wrote:

Am Sonntag, den 04.02.2018, 13:58 +0100 schrieb Thomas Trepl:

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?


Upstream allready caught that issue and they said it will be fixed in
"next week's round of minor releases" (10.2).  So I think we can just
wait a few days and problem will went away...
For urgent fix, just do

sed -e "s/copy_file_range/rewind_&/" -i src/bin/pg_rewind/copy_fetch.c

This is what upstream did.


Please go ahead and put that into the book for now.  We always check sed 
and patch instructions when a new version of a package is released.


  -- Bruce

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


Re: [blfs-dev] Compile issue postgresql

2018-02-04 Thread Bruce Dubbs

Thomas Trepl wrote:

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?


If you are going to go ahead and make the fix, then we do not need a 
ticket.  We use the tickets to ensure we do not forget.


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


Re: [blfs-dev] Compile issue postgresql

2018-02-04 Thread Thomas Trepl
Am Sonntag, den 04.02.2018, 13:58 +0100 schrieb Thomas Trepl:
> 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?

Upstream allready caught that issue and they said it will be fixed in
"next week's round of minor releases" (10.2).  So I think we can just
wait a few days and problem will went away...
For urgent fix, just do

sed -e "s/copy_file_range/rewind_&/" -i src/bin/pg_rewind/copy_fetch.c

This is what upstream did.

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


Re: [blfs-dev] Compile issue postgresql

2018-02-04 Thread Thomas Trepl
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


Re: [blfs-dev] Compile issue postgresql

2018-02-04 Thread Armin K.
On Sun, 2018-02-04 at 11:42 +0100, Thomas Trepl wrote:
> Hi,
> 
> got a abort message when compiling postgresql:
> 
> gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-
> statement -Wendif-labels -Wmissing-format-attribute -Wformat-security
> -fno-strict-aliasing -fwrapv -fexcess-precision=standard -O2
> -I../../../src/interfaces/libpq -DFRONTEND -I../../../src/include  -
> 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,
>  ^~~
> make[3]: *** [: copy_fetch.o] Fehler 1
> make[3]: Verzeichnis „/tmp/postgresql/build/postgresql-
> 10.1/src/bin/pg_rewind“ wird verlassen
> make[2]: *** [Makefile:40: all-pg_rewind-recurse] Fehler 2
> make[2]: Verzeichnis „/tmp/postgresql/build/postgresql-10.1/src/bin“
> wird verlassen
> make[1]: *** [Makefile:37: all-bin-recurse] Fehler 2
> make[1]: Verzeichnis „/tmp/postgresql/build/postgresql-10.1/src“ wird
> verlassen
> make: *** [GNUmakefile:11: all-src-recurse] Fehler 2
> 
> 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).
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page