Thread: v15rc2(/v15rc1/v15b4) shadowbuild fails when using src from symlink
L.S. Just like v15rc1, the second rc fails to compile when using the source from a symlink. => openSUSE Leap 15.4 (gcc v7.5.0 / make v4.2.1) => unpack source => create a symlink $PGSRCDIR to the source(-rc2) folder => create a build folder $PGDIR and from within that: $PGSRCDIR/configure --prefix=$PGDIR/install --enable-thread-safety make -j2 => fails on the following: (...) configure: using compiler=gcc (SUSE Linux) 7.5.0 configure: using CFLAGS=-Wall -Wmissing-prototypes -Wpointer-arith - Wdeclaration-after-statement -Werror=vla -Wendif-labels -Wmissing-format- attribute -Wimplicit-fallthrough=3 -Wformat-security -fno-strict-aliasing - fwrapv -fexcess-precision=standard -Wno-format-truncation -O2 configure: using CPPFLAGS= -D_GNU_SOURCE -I/usr/include/libxml2 configure: using LDFLAGS= -Wl,--as-needed preparing build tree... done configure: creating ./config.status config.status: creating GNUmakefile config.status: creating src/Makefile.global config.status: creating src/include/pg_config.h config.status: creating src/include/pg_config_ext.h config.status: creating src/interfaces/ecpg/include/ecpg_config.h config.status: linking /home/development/postgresql-15.0/src/backend/port/tas/ dummy.s to src/backend/port/tas.s config.status: linking /home/development/postgresql-15.0/src/backend/port/ posix_sema.c to src/backend/port/pg_sema.c config.status: linking /home/development/postgresql-15.0/src/backend/port/ sysv_shmem.c to src/backend/port/pg_shmem.c config.status: linking /home/development/postgresql-15.0/src/include/port/ linux.h to src/include/pg_config_os.h config.status: linking /home/development/postgresql-15.0/src/makefiles/ Makefile.linux to src/Makefile.port + make -j2 make -C ./src/backend generated-headers make[1]: Entering directory '/home/development/4suse15.4-x86_64/ postgresql-15.0/src/backend' make[1]: *** No rule to make target 'generated-headers'. Stop. make[1]: Leaving directory '/home/development/4suse15.4-x86_64/ postgresql-15.0/src/backend' make: *** [src/Makefile.global:390: submake-generated-headers] Error 2 => when using the real source folder instead of the symlink, the same compile/ script finishes fine -- Best, Frank.
On 2022-Oct-06, Frank van Vugt wrote: > L.S. > > Just like v15rc1, the second rc fails to compile when using the source from a > symlink. Yeah, nobody has claimed to have fixed this, so this is not surprising. You didn't reply to Michael's reply to your previous report; any thoughts on that? Maybe if you propose a fix, we can discuss it. -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
On Thu, Oct 06, 2022 at 06:57:53PM +0200, Alvaro Herrera wrote: > Yeah, nobody has claimed to have fixed this, so this is not surprising. > You didn't reply to Michael's reply to your previous report; any > thoughts on that? > > Maybe if you propose a fix, we can discuss it. FWIW, if that proves to be simple, perhaps there is a point in doing it. However, we also need to take into account that this would be unstressed by the buildfarm. And there is also an extra factor to think about here: meson. The tool only supports VPATH-like builds, which is what Frank is doing, and a quick test shows me that it is possible to specify a link to the source folder in the meson command (last argument of the meson command), which is also something Frank does here. -- Michael
Attachment
On 2022-Oct-07, Michael Paquier wrote: > On Thu, Oct 06, 2022 at 06:57:53PM +0200, Alvaro Herrera wrote: > > Yeah, nobody has claimed to have fixed this, so this is not surprising. > > You didn't reply to Michael's reply to your previous report; any > > thoughts on that? > > > > Maybe if you propose a fix, we can discuss it. > > FWIW, if that proves to be simple, perhaps there is a point in doing > it. However, we also need to take into account that this would be > unstressed by the buildfarm. Agreed, getting a supporting buildfarm animal set up would be an important step if we wanted to accept such a patch. > And there is also an extra factor to think about here: meson. The > tool only supports VPATH-like builds, which is what Frank is doing, > and a quick test shows me that it is possible to specify a link to the > source folder in the meson command (last argument of the meson > command), which is also something Frank does here. Ah! So maybe a more convenient way forward is to reject any patch for adding support for this in autoconf, and tell Frank to use our Meson build instead. (Not available until 16, but of course so would be the case with whatever patches he came up with at this point.) Our autoconf build system is on the way out anyway: even if it's not to be removed in the near future, ISTM the writing is now in the stone that it'll eventually be gone. So adding a new feature is likely a waste of time. -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/ "You don't solve a bad join with SELECT DISTINCT" #CupsOfFail https://twitter.com/connor_mc_d/status/1431240081726115845
Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> Our autoconf build system is on the way out anyway: even if it's not to
> be removed in the near future, ISTM the writing is now in the stone that
> it'll eventually be gone. So adding a new feature is likely a waste of
> time.
+1, I think we're committed to spending future effort on the meson
infrastructure not the autoconf infrastructure.
regards, tom lane
Hi Alvaro/Michael/Tom, Op donderdag 6 oktober 2022 18:57:53 CEST schreef Alvaro Herrera: > On 2022-Oct-06, Frank van Vugt wrote: > > Just like v15rc1, the second rc fails to compile when using the source > > from a symlink. > > Yeah, nobody has claimed to have fixed this, so this is not surprising. Agreed and it's obviously not a 'big deal'. Also there was a lot more going on during the commitfest etc, so I just wanted to 'repeat' the message until someone was able to find some 'spare time' to reply ;) > You didn't reply to Michael's reply to your previous report; any > thoughts on that? argh, it seems like I completely missed his initial reply (probably trusted too much on the 'cc the original sender' ;) ). Sorry 'bout that. @Michael "why such an exotic way to build" -> well, 'a bit archaïc' maybe, just something that came about when I was often building for various architectures using the same build source, but in no way this is something that 'needs to be this way' for me, so I'm happy to adapt ;) > [AH] Maybe if you propose a fix, we can discuss it. > [MP] Agreed, getting a supporting buildfarm animal set up would be > an important step if we wanted to accept such a patch. > [AH] maybe a more convenient way forward is <cut> tell Frank to use > our Meson build instead. (Not available until 16) > [TL] +1, I think we're committed to spending future effort on > the meson infrastructure not the autoconf infrastructure. Tnx guys for all the background info, I couldn't agree more, fixing this in the autoconf realm seems a moot point. During v14/v15 I'll just handle this by building in a slightly different way, as soon as the meson infrastructure shows up, we'll take if from there (if needed at all). -- Best, Frank.