From: "Wouter Bijlsma" <wouter@wouterbijlsma.nl>
To: 73582@debbugs.gnu.org
Subject: bug#73582: guile-3.0 build system adding unnecessary pkg-config & guile-config compile flags
Date: Mon, 30 Sep 2024 21:43:27 +0200 [thread overview]
Message-ID: <89ad74f1-eaff-44fa-83f3-151404e19053@app.fastmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 1587 bytes --]
Hello,
I believe I may have found a bug in the guile 3.0 build system.
When configuring and building on systems that have libgmp installed, the guile build system will add '-I$LIBGMP_PREFIX' to the set of compiler flags reported by 'pkg-config --cflags guile-3.0' (and hence also 'guile-config compile'). At least on my configuration (Arch Linux), the value of $LIBGMP_PREFIX is (predictably) '/usr', which results in '-I/usr' being added to the GUILE_CFLAGS in the 'configure' script, which will subsequently be substituted for @GUILE_CFLAGS@ to generate the meta/guile-3.0.pc pkg-config script that will be installed along with guile.
The net result is that any project that uses pkg-config to find guile (e.g. from CMake) will implicitly add -I/usr to its own compiler flags, which is not just unnecessary but also causes IDE's that use the compiler flags to find include directories to index, to recursively have to index everything in /usr (which is a lot).
I cannot imagine a prefix path to be intentionally added as an include path, and simply removing it does not break anything (not building guile itself, nor building projects that depend on it), so I assume this is a bug?
The code that adds $LIBGMP_PREFIX to the $GUILE_CFLAGS is in the 'configure.ac' script, which defines the GMP checking code, to end up in the configure script. As mentioned, if I simply remove it from the configure script, guile compiles fine, and projects that use the generated pkg-config also build without issue.
All this is using the latest guile 3.0.10 tarball by the way.
Regards,
-Wouter
[-- Attachment #2: Type: text/html, Size: 1929 bytes --]
reply other threads:[~2024-09-30 19:43 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=89ad74f1-eaff-44fa-83f3-151404e19053@app.fastmail.com \
--to=wouter@wouterbijlsma.nl \
--cc=73582@debbugs.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).