Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bad pkg-config configuration when building system packages with prefix=/usr #1802

Open
freedxmgxd opened this issue Oct 26, 2024 · 12 comments
Open

Comments

@freedxmgxd
Copy link

Cantera Version 3.0.0

When I tried to run the example of C++ program get error in math.h
g++ main/main.cpp -o myProgram -std=c++17 $(pkg-config --cflags --libs cantera)

I get the error:

In file included from /usr/include/cantera/base/ct_defs.h:19,
                 from /usr/include/cantera/base/ctexceptions.h:14,
                 from /usr/include/cantera/base/Solution.h:9,
                 from /usr/include/cantera/core.h:12,
                 from main/main.cpp:1:
/usr/include/c++/14.2.1/cmath:47:15: fatal error: math.h: No such file or directory
   47 | #include_next <math.h>
      |               ^~~~~~~~
compilation terminated.

The math.h is installed and seems works fine in another projects.

@speth
Copy link
Member

speth commented Oct 26, 2024

What is the output from the following two commands?

  • pkg-config --cflags --libs cantera
  • g++ -E -x c++ - -v < /dev/null

And can you attach a copy of the cantera.pc file, which I think will have been installed in /usr/lib/pkgconfig/ or some similar directory?

@freedxmgxd
Copy link
Author

pkg-config --cflags --libs cantera

-isystem /usr/include/eigen3 -isystem /usr/include/sundials -std=c++17 -pthread -isystem /usr/include -Wl,-rpath,/usr/lib -lcantera_shared -lfmt -lpthread
g++ -E -x c++ - -v < /dev/null

Using built-in specs.
COLLECT_GCC=g++
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --enable-languages=ada,c,c++,d,fortran,go,lto,m2,objc,obj-c++,rust --enable-bootstrap --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://gitlab.archlinux.org/archlinux/packaging/packages/gcc/-/issues --with-build-config=bootstrap-lto --with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit --enable-cet=auto --enable-checking=release --enable-clocale=gnu --enable-default-pie --enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object --enable-libstdcxx-backtrace --enable-link-serialization=1 --enable-linker-build-id --enable-lto --enable-multilib --enable-plugin --enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch --disable-werror
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.2.1 20240910 (GCC)
COLLECT_GCC_OPTIONS='-E' '-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-pc-linux-gnu/14.2.1/cc1plus -E -quiet -v -D_GNU_SOURCE - -mtune=generic -march=x86-64 -dumpbase -
ignoring nonexistent directory "/usr/lib/gcc/x86_64-pc-linux-gnu/14.2.1/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-pc-linux-gnu/14.2.1/../../../../include/c++/14.2.1
 /usr/lib/gcc/x86_64-pc-linux-gnu/14.2.1/../../../../include/c++/14.2.1/x86_64-pc-linux-gnu
 /usr/lib/gcc/x86_64-pc-linux-gnu/14.2.1/../../../../include/c++/14.2.1/backward
 /usr/lib/gcc/x86_64-pc-linux-gnu/14.2.1/include
 /usr/local/include
 /usr/lib/gcc/x86_64-pc-linux-gnu/14.2.1/include-fixed
 /usr/include
End of search list.
# 0 "<stdin>"
# 0 "<built-in>"
# 0 "<command-line>"
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 0 "<command-line>" 2
# 1 "<stdin>"
COMPILER_PATH=/usr/lib/gcc/x86_64-pc-linux-gnu/14.2.1/:/usr/lib/gcc/x86_64-pc-linux-gnu/14.2.1/:/usr/lib/gcc/x86_64-pc-linux-gnu/:/usr/lib/gcc/x86_64-pc-linux-gnu/14.2.1/:/usr/lib/gcc/x86_64-pc-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-pc-linux-gnu/14.2.1/:/usr/lib/gcc/x86_64-pc-linux-gnu/14.2.1/../../../../lib/:/lib/../lib/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-pc-linux-gnu/14.2.1/../../../:/lib/:/usr/lib/

cantera.pc.txt

I ascrescented .txt in the end of the cantera/pc file so I can attach it here.

@speth
Copy link
Member

speth commented Oct 27, 2024

Can you share the contents of your cantera.conf file? If you're using packages installed in the system default locations, you shouldn't need to specify those locations (for example, /usr/include) to SCons when building Cantera. I think this may be part of the problem here, judging from this StackOverflow post.

@ischoegl
Copy link
Member

In general, I believe it to be preferable to post about installation question on Cantera's user group.

@freedxmgxd
Copy link
Author

freedxmgxd commented Oct 28, 2024

This the cantera.conf

cantera.conf.txt

I tried to build without locations, don't works
However, manually changing -isystem /usr/include -I /usr/include works fine, but I would like to persist this in pkg-config if possible.

Also remove -isystem /usr/include at all seems works too, running g++ main/main.cpp -o myProgram -std=c++17 -pthread -Wl,-rpath,/usr/lib -lcantera_shared -lfmt -lpthread

@speth
Copy link
Member

speth commented Nov 15, 2024

I'm not sure which Linux variant you're using, but I think it's generally recommended that installing software with a PREFIX of /usr should be avoided except for things installed by the system package manager (apt, dnf, etc.) and that software installed by other means should be installed to /usr/local.

The issue here seems to be with re-specifying default system include directories with the -isystem argument, which causes some of these directories to be handled in the wrong order relative to other built-in include directories. The problem is there's no consistent way for SCons to know what all the default system include directories are, so we can't just automatically remove them.

@ischoegl - I'd like to leave this open and think about if there is anything we can do to avoid creating this sort of problem.

@freedxmgxd
Copy link
Author

I fixed manually changing the pkg-config, I use Arch, and plan to upload the stable version package to AUR, I think there's one for the git version, and maybe do some workaround to avoid the problem.

@freedxmgxd
Copy link
Author

@ischoegl - I'd like to leave this open and think about if there is anything we can do to avoid creating this sort of problem.

In the src/cantera/platform/posix/SConscript, implement a check to view if /usr is in dir and ignore it. Does this work?
I don't have experience with scons, and don't know if this will break another install, but seems I solution to me.

@speth
Copy link
Member

speth commented Nov 16, 2024

Can you try specifying the package_build=y option to scons build ...? I think this should leave out some compiler flags in the generated build scripts for things that shouldn't be necessary if everything is installed in system default locations.

@freedxmgxd
Copy link
Author

I make a workaround, by change SConscript and cantera.pc.in, that's seen to works fine.

SConscript

...
if localenv["package_build"]:
    ...
    if localenv["prefix"] != "/usr":
        localenv["pc_libs_default"] = "-L${libdir} -Wl,-rpath,${libdir}"
        localenv["pc_cflags_default"] = "-isystem ${includedir}"
    else:
        localenv["pc_libs_default"] = "-Wl,-rpath"
        localenv["pc_cflags_default"] = "-isystem"
else:
    ...
    
    localenv["pc_libs_default"] = "-L${libdir} -Wl,-rpath,${libdir}"
    localenv["pc_cflags_default"] = "-isystem ${includedir}"
...

and cantera.pc.in,

...
Libs: @pc_libs_default@ @pc_libdirs@ @pc_libs@
Cflags: @pc_cflags@ @pc_cflags_default@

Should I made a pull request with this or doesn't need?
I don't know if this works perfectly, but worked well for me. (Using Archlinux e PKGBUILD)

my build command: scons -j $(nproc) build prefix="/usr" system_eigen='y' system_sundials='n' googletest='system' system_fmt='y' package_build='y' (I don't use system_sundials because I using version 3.0 of cantera, and sundials 7 on system)

@speth
Copy link
Member

speth commented Nov 16, 2024

A patch to simplify this for the sake of building system packages would certainly be welcome. For the Ubuntu packages, we just patch the cantera.pc after the fact, but it would be nice not to have to do that.

I'm not sure what you've shown above is what's needed, though. I assume the value of ${libdir} is ultimately /usr/lib and {$includedir} is /usr/include, right? In which case, there shouldn't be any need to specify these compiler flags via pkg-config.

@freedxmgxd
Copy link
Author

The if statement can be put outside of package_build, and this will work for every build but I don't know if this will break some system. But I think that for another dir like /usr/local/include and / usr/local/lib, the workaround that I propose seens works well, I have another system to try, but should work for Ubuntu too.

@speth speth changed the title fatal error: math.h: No such file or directory Bad pkg-config configuration when building system packages with prefix=/usr Nov 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants