Unable to build from source #2770

zdm · 2020-12-22T05:39:28Z

Relevant system information:

OS: Fedora 33
PostgreSQL version 12.5
TimescaleDB version 2.0.0
Installation method: "source"

Describe the bug
I get the error below when trying to build it from source.

clone and checkout latest release;

run:

./bootstrap -DREGRESS_CHECKS=OFF
cd build && gmake

[ 33%] Building C object src/CMakeFiles/timescaledb.dir/jsonb_utils.c.o
[ 34%] Building C object src/CMakeFiles/timescaledb.dir/license_guc.c.o
[ 34%] Building C object src/CMakeFiles/timescaledb.dir/partitioning.c.o
In file included from /usr/pgsql-12/include/server/postgres.h:46,
                 from /root/rpmbuild/BUILD/timescaledb/src/partitioning.c:6:
/root/rpmbuild/BUILD/timescaledb/src/partitioning.c: In function 'ts_partitioning_info_create':
/root/rpmbuild/BUILD/timescaledb/src/partitioning.c:187:2: error: 'strncpy' specified bound 64 equals destination size [-Werror=stringop-truncation]
  187 |  StrNCpy(pinfo->partfunc.name, partfunc, NAMEDATALEN);
      |  ^~~~~~~
/root/rpmbuild/BUILD/timescaledb/src/partitioning.c:188:2: error: 'strncpy' specified bound 64 equals destination size [-Werror=stringop-truncation]
  188 |  StrNCpy(pinfo->column, partcol, NAMEDATALEN);
      |  ^~~~~~~
/root/rpmbuild/BUILD/timescaledb/src/partitioning.c:196:2: error: 'strncpy' specified bound 64 equals destination size [-Werror=stringop-truncation]
  196 |  StrNCpy(pinfo->partfunc.schema, schema, NAMEDATALEN);
      |  ^~~~~~~
cc1: all warnings being treated as errors
gmake[2]: *** [src/CMakeFiles/timescaledb.dir/build.make:628: src/CMakeFiles/timescaledb.dir/partitioning.c.o] Error 1
gmake[1]: *** [CMakeFiles/Makefile2:1011: src/CMakeFiles/timescaledb.dir/all] Error 2
gmake: *** [Makefile:149: all] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.u8LEud (%build)


RPM build errors:
    Bad exit status from /var/tmp/rpm-tmp.u8LEud (%build)

The text was updated successfully, but these errors were encountered:

jgoff · 2020-12-22T06:50:24Z

same error also seen when trying to build timscaledb 2.0.0 with postgres 12.5 on kali 2019.4 (x86_64), with GCC version 9.3.0

k-rus · 2020-12-22T07:30:23Z

@zdm @jgoff Can you provide -DWARNINGS_AS_ERRORS=OFF to the bootstrap? It should solve treating this warning as error?

zdm · 2020-12-22T07:32:47Z

maybe it will be better to fix this?

…

On 22.12.2020 09:30, Ruslan Fomkin wrote: @zdm <https://github.com/zdm> @jgoff <https://github.com/jgoff> Can you provide |-DWARNINGS_AS_ERRORS=OFF| to the bootstrap? It should solve treating this warning as error? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2770 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAH2MSDBMXZEEB5R2ZO2YJTSWBDJ5ANCNFSM4VFEXRWA>.

k-rus · 2020-12-22T08:10:04Z

maybe it will be better to fix this?

Yes.

CyberDem0n · 2020-12-22T08:16:02Z

For me it fails with:

[ 25%] Building C object src/CMakeFiles/timescaledb.dir/dimension_vector.c.o
/home/akukushkin/git/timescaledb/src/dimension_vector.c: In function ‘ts_dimension_vec_add_slice’:
/home/akukushkin/git/timescaledb/src/dimension_vector.c:41:18: error: assuming signed overflow does not occur when assuming that (X + c) < X is always false [-Werror=strict-overflow]
  if (vec != NULL && vec->capacity >= new_capacity)
      ~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/akukushkin/git/timescaledb/src/dimension_vector.c: In function ‘ts_dimension_vec_add_unique_slice’:
/home/akukushkin/git/timescaledb/src/dimension_vector.c:41:18: error: assuming signed overflow does not occur when assuming that (X + c) < X is always false [-Werror=strict-overflow]
  if (vec != NULL && vec->capacity >= new_capacity)
      ~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/akukushkin/git/timescaledb/src/dimension_vector.c: In function ‘ts_dimension_vec_add_slice_sort’:
/home/akukushkin/git/timescaledb/src/dimension_vector.c:41:18: error: assuming signed overflow does not occur when assuming that (X + c) < X is always false [-Werror=strict-overflow]
  if (vec != NULL && vec->capacity >= new_capacity)
      ~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
src/CMakeFiles/timescaledb.dir/build.make:614: recipe for target 'src/CMakeFiles/timescaledb.dir/dimension_vector.c.o' failed

It is sort of strange to have defaults that most likely would fail.

Another problem is that due to the c90397f the bootstrap script fails on ubuntu 18.04 because there is only cmake 3.10 available, but perfectly works after manually changing requirement in the CMakeLists.txt.

jgoff · 2020-12-22T13:43:42Z

@zdm @jgoff Can you provide -DWARNINGS_AS_ERRORS=OFF to the bootstrap? It should solve treating this warning as error?
@k-rus , confirming that it compiles OK with this workaround flag

k-rus · 2020-12-22T14:35:14Z

Thank you for confirmation. We will look to remove the need for this flag in future release.

In contrast to the default for CMake files, `Release` is used as the default in `CMakeFiles.txt` which causes the `bootstrap` script to do a release build with development flags, in particular `-Werror`. Since warnings are triggered in a release build, this cause the build to fail while a debug build works fine. This commit fixes this by removing the `-Werror` flag (by setting `WARNINGS_AS_ERRORS` to `OFF`) on anything that is not a debug build and also disable the warnings that (currently) trigger the warnings in the release build. The commit also changes the GitHub workflows to run without `WARNINGS_AS_ERRORS` since it should always work without this option regardless of build type. Fixes timescale#2770

In contrast to the default for CMake files, `Release` is used as the default in `CMakeFiles.txt` which causes the `bootstrap` script to do a release build with development flags, in particular `-Werror`. Since warnings are triggered in a release build, this cause the build to fail while a debug build works fine. This commit fixes this by removing the `-Werror` flag (by setting `WARNINGS_AS_ERRORS` to `OFF`) on anything that is not a debug build and also disable the warnings that (currently) trigger the warnings in the release build. The commit also changes the GitHub workflows to run without `WARNINGS_AS_ERRORS` since it should always work without this option regardless of build type (on release build this should be disabled, on debug builds this should be enabled). Fixes timescale#2770

In contrast to the default for CMake files, `Release` is used as the default in `CMakeFiles.txt` which causes the `bootstrap` script to do a release build with development flags, in particular `-Werror`. Since warnings are triggered in a release build, this cause the build to fail while a debug build works fine. This commit fixes this by removing the `-Werror` flag (by setting `WARNINGS_AS_ERRORS` to `OFF`) on anything that is not a debug build and also disable the warnings that (currently) trigger the warnings in the release build. The commit also changes some of the GitHub workflows to run without `WARNINGS_AS_ERRORS` since it should always work without this option regardless of build type (on release build this should be disabled, on debug builds this should be enabled). But it is set to `ON` for the full release and debug builds to ensure that we do not generate any warnings, which will capture new surfacing warnings. Fixes timescale#2770

In contrast to the default for CMake files, `Release` is used as the default in `CMakeFiles.txt` which causes the `bootstrap` script to do a release build with development flags, in particular `-Werror`. Since warnings are triggered in a release build, this cause the build to fail while a debug build works fine. This commit fixes this by removing the `-Werror` flag (by setting `WARNINGS_AS_ERRORS` to `OFF`) on anything that is not a debug build and also disable the warnings that (currently) trigger the warnings in the release build. The commit also changes some of the GitHub workflows to run without `WARNINGS_AS_ERRORS` since it should always work without this option regardless of build type (on release build this should be disabled, on debug builds this should be enabled). But it is set to `ON` for the full release and debug builds to ensure that we do not generate any warnings, which will capture new surfacing warnings. Fixes #2770

In contrast to the default for CMake files, `Release` is used as the default in `CMakeFiles.txt` which causes the `bootstrap` script to do a release build with development flags, in particular `-Werror`. Since warnings are triggered in a release build, this cause the build to fail while a debug build works fine. This commit fixes this by removing the `-Werror` flag (by setting `WARNINGS_AS_ERRORS` to `OFF`) on anything that is not a debug build and also disable the warnings that (currently) trigger the warnings in the release build. The commit also changes some of the GitHub workflows to run without `WARNINGS_AS_ERRORS` since it should always work without this option regardless of build type (on release build this should be disabled, on debug builds this should be enabled). But it is set to `ON` for the full release and debug builds to ensure that we do not generate any warnings, which will capture new surfacing warnings. Fixes timescale#2770

In contrast to the default for CMake files, `Release` is used as the default in `CMakeFiles.txt` which causes the `bootstrap` script to do a release build with development flags, in particular `-Werror`. Since warnings are triggered in a release build, this cause the build to fail while a debug build works fine. This commit fixes this by removing the `-Werror` flag (by setting `WARNINGS_AS_ERRORS` to `OFF`) on anything that is not a debug build and also disable the warnings that (currently) trigger the warnings in the release build. The commit also changes some of the GitHub workflows to run without `WARNINGS_AS_ERRORS` since it should always work without this option regardless of build type (on release build this should be disabled, on debug builds this should be enabled). But it is set to `ON` for the full release and debug builds to ensure that we do not generate any warnings, which will capture new surfacing warnings. Fixes #2770

To allow us to use specific glibc 2.33+ features, we need to find a way to run glibc 2.33. Running multiple glibc versions inside the same container is something we'd like to avoid, we've seen multiple glibc related bugs in our lifetime, adding multiple glibc versions in the mix would make debugging harder. Debian (and rust:debian) has served us well, however even Debian's latest release (bullseye, August 2021) cannot give us glibc 2.33. Ubuntu however does give us glibc 2.33 - as Ubuntu is based upon Debian the changes required are not that big for this Docker Image. Most of the tools we use will be the same across the board, as most of our tools our installed using external repositories. Some significant changes to get here are required though: * install rust using rustup-init There was some (valid) criticism[1], around using rust as a base for the image, instead of Debian. As Rust does not offer an Ubuntu variant, we are no longer using a rust-flavored Docker Image as a base, however, we do copy the exact rust installation sequence - including comparing hashes for sanity for installing Rust. * deprecate `apt-key` usage Ubuntu 21.04 seems to still allow apt-key, however, in the future apt-key usage will be deprecated. As the tweaking to get this fixed for Ubuntu 21.10 was already done, I decided it best to keep it in here. * remove PostGIS 2.5 support There is no packaged PostGIS 2.5 available for Ubuntu 21.04. We however have seen no evidence of PostGIS 2.5 usage with our Docker Image, we do see evidence of usage of PostGIS 3, which is the default. Dropping support for 2.5 therefore does not seem to be such a major issue * disable errors as warnings These build errors are seen on building older TimescaleDB versions against a recent glibc. For more details, see[2] 1: #140 (comment) 2: timescale/timescaledb#2770 :# modified: .github/workflows/build_image.yaml

To allow us to use specific glibc 2.33+ features, we need to find a way to run glibc 2.33. Running multiple glibc versions inside the same container is something we'd like to avoid, we've seen multiple glibc related bugs in our lifetime, adding multiple glibc versions in the mix would make debugging harder. Debian (and rust:debian) has served us well, however even Debian's latest release (bullseye, August 2021) cannot give us glibc 2.33. Ubuntu however does give us glibc 2.33 - as Ubuntu is based upon Debian the changes required are not that big for this Docker Image. Most of the tools we use will be the same across the board, as most of our tools our installed using external repositories. Some significant changes to get here are required though: * install rust using rustup-init There was some (valid) criticism[1], around using rust as a base for the image, instead of Debian. As Rust does not offer an Ubuntu variant, we are no longer using a rust-flavored Docker Image as a base, however, we do copy the exact rust installation sequence - including comparing hashes for sanity for installing Rust. * deprecate `apt-key` usage Ubuntu 21.04 seems to still allow apt-key, however, in the future apt-key usage will be deprecated. As the tweaking to get this fixed for Ubuntu 21.10 was already done, I decided it best to keep it in here. * remove PostGIS 2.5 support There is no packaged PostGIS 2.5 available for Ubuntu 21.04. We however have seen no evidence of PostGIS 2.5 usage with our Docker Image, we do see evidence of usage of PostGIS 3, which is the default. Dropping support for 2.5 therefore does not seem to be such a major issue * disable errors as warnings These build errors are seen on building older TimescaleDB versions against a recent glibc. For more details, see[2] 1: #140 (comment) 2: timescale/timescaledb#2770

k-rus added build Issues related to building TimescaleDB or using its binaries docs-update-needed question labels Dec 22, 2020

k-rus removed question docs-update-needed labels Dec 22, 2020

k-rus mentioned this issue Dec 28, 2020

CMake doesn't propagate CPPFLAGS and LDFLAGS used when building PostgreSQL #2777

Closed

1000101 mentioned this issue Jan 8, 2021

postgresqlPackages.timescaledb: 1.7.4 -> 2.0.0 NixOS/nixpkgs#108784

Merged

10 tasks

k-rus mentioned this issue Jan 13, 2021

Make timescaledb 2.0.0 from source occurs error at catalog.c.o #2816

Closed

k-rus assigned mkindahl Jan 15, 2021

This was referenced Jan 29, 2021

Build errors with Pg 12.5 and TimescaleDB 2.0.1 #2881

Closed

Build issue on Alpine Linux #2882

Closed

mkindahl mentioned this issue Feb 2, 2021

Change bootstrap and CMake defaults #2893

Merged

erimatnor mentioned this issue Feb 9, 2021

Use cppflags and ldflags from pg_config. #2776

Closed

mkindahl closed this as completed in #2893 Feb 9, 2021

mkindahl mentioned this issue Feb 19, 2021

2.0.2 cherry pick #2960

Merged

1000101 mentioned this issue Apr 14, 2021

postgresqlPackages.timescaledb: 2.1.1 -> 2.2.0 NixOS/nixpkgs#119388

Merged

10 tasks

feikesteenbergen mentioned this issue Sep 9, 2021

Use Ubuntu as a base for our Docker Image timescale/timescaledb-docker-ha#158

Merged

1 task

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Unable to build from source #2770

Unable to build from source #2770

zdm commented Dec 22, 2020

jgoff commented Dec 22, 2020

k-rus commented Dec 22, 2020

zdm commented Dec 22, 2020 via email •

edited

k-rus commented Dec 22, 2020

CyberDem0n commented Dec 22, 2020

jgoff commented Dec 22, 2020

k-rus commented Dec 22, 2020

Unable to build from source #2770

Unable to build from source #2770

Comments

zdm commented Dec 22, 2020

jgoff commented Dec 22, 2020

k-rus commented Dec 22, 2020

zdm commented Dec 22, 2020 via email • edited

k-rus commented Dec 22, 2020

CyberDem0n commented Dec 22, 2020

jgoff commented Dec 22, 2020

k-rus commented Dec 22, 2020

zdm commented Dec 22, 2020 via email •

edited