Community Packages

Please read this before reporting a bug:
http://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#66441 - [paraview] Fix CFLAGS, CXXFLAGS

Attached to Project: Community Packages
Opened by Christian Cornelssen (ccorn) - Tuesday, 28 April 2020, 06:14 GMT
Last edited by Bruno Pagani (ArchangeGabriel) - Tuesday, 28 July 2020, 08:41 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Bruno Pagani (ArchangeGabriel)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:

In order to build with the recent `hdf5` upgrade, the `PKGBUILD` for `paraview-5.8.0-5` uses the following `cmake` options:

~~~ sh
-DCMAKE_C_FLAGS="-DH5_USE_110_API" \
-DCMAKE_CXX_FLAGS="-DH5_USE_110_API" \
~~~

Specifying those causes the environment's `CFLAGS`, `CXXFLAGS` to be ignored, cf. https://cmake.org/cmake/help/latest/envvar/CXXFLAGS.html#envvar:CXXFLAGS , which is wrong.

Removing those `cmake` options and instead beginning `build()` with

~~~ sh
# H5Oget_info_by_name, H5Oget_info have changed prototypes in HDF5 1.12
CXXFLAGS+=" -DH5_USE_110_API"
CFLAGS+=" -DH5_USE_110_API"
export CFLAGS CXXFLAGS
~~~

works correctly.
An alternative would be `-DCMAKE_CXX_FLAGS="$CXXFLAGS -DH5_USE_110_API"` etc, but the proposed solution keeps environment and CMake variables in sync.

Steps to reproduce:

Compare `$srcdir/build/build.ninja` (watch out for `FLAGS =`) with the different `PKGBUILD` variants.
This task depends upon

Closed by  Bruno Pagani (ArchangeGabriel)
Tuesday, 28 July 2020, 08:41 GMT
Reason for closing:  Fixed
Additional comments about closing:  5.8.0-9
Comment by Christian Cornelssen (ccorn) - Friday, 08 May 2020, 06:15 GMT
It gets worse. The [CMake docs](https://cmake.org/cmake/help/latest/manual/cmake-env-variables.7.html) do not mention `CPPFLAGS` at all, so that variable always gets ignored by CMake. Therefore, ideally we should begin `build()` with

~~~ sh
CPPFLAGS+=" -DH5_USE_110_API" # space before -D needed
# ...
cmake ... \
-DCMAKE_C_FLAGS="$CPPFLAGS $CFLAGS" \
-DCMAKE_CXX_FLAGS="$CPPFLAGS $CXXFLAGS"
~~~
where the mentioned `cmake` commandline fragment should be used in every CMake-based `PKGBUILD`. This way, the environment keeps following GNU autoconf standards, and CMake still gets all the tweaks set in `makepkg.conf` (which usually includes `-D_FORTIFY_SOURCE=2` in `CPPFLAGS`, `-fno-plt` in `C*FLAGS` and more secure `LDFLAGS`).
Comment by Christian Cornelssen (ccorn) - Friday, 08 May 2020, 16:52 GMT
See also the Archwiki on [CMake and `C*FLAGS`](https://wiki.archlinux.org/index.php/CMake_package_guidelines#Lack_of_support_for_CPPFLAGS_environment_variable).
Thanks to AUR user bartus for unearthing that link in the [paraview-opt thread](https://aur.archlinux.org/packages/paraview-opt/).

Loading...