Bug 95005 - zstd.h not found if installed in non-system prefix
Summary: zstd.h not found if installed in non-system prefix
Status: ASSIGNED
Alias: None
Product: gcc
Classification: Unclassified
Component: bootstrap (show other bugs)
Version: 10.1.0
: P3 normal
Target Milestone: ---
Assignee: Michael Kuhn
URL: https://gcc.gnu.org/pipermail/gcc-pat...
Keywords: build, patch
Depends on:
Blocks:
 
Reported: 2020-05-08 10:42 UTC by Michael Kuhn
Modified: 2021-05-04 16:48 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2020-05-09 00:00:00


Attachments
Add zstd include directory (428 bytes, patch)
2020-05-08 10:42 UTC, Michael Kuhn
Details | Diff
Patch candidate (559 bytes, application/mbox)
2020-05-11 07:18 UTC, Martin Liška
Details
Updated zstd patch (633 bytes, patch)
2020-05-12 10:49 UTC, Michael Kuhn
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Kuhn 2020-05-08 10:42:34 UTC
Created attachment 48482 [details]
Add zstd include directory

While adding GCC 10.1.0 to Spack, I ran into a problem with zstd: When specifying a non-system prefix with --with-zstd (Spack installs each package in its own prefix), the build of lto-compress.o failed because it could not find the zstd.h header.

The attached patch fixes the problem. It should probably be changed to export the appropriate compiler flag from configure.ac to avoid the ifeq in the Makefile. However, I wanted to avoid touching configure.ac so we do not have to regenerate configure.
Comment 1 Martin Liška 2020-05-11 07:18:25 UTC
Created attachment 48503 [details]
Patch candidate

Thank you for the bug report.
I'm sending a better patch, can you please test it?
Comment 2 Michael Kuhn 2020-05-11 08:40:01 UTC
(In reply to Martin Liška from comment #1)
> Thank you for the bug report.
> I'm sending a better patch, can you please test it?

I applied your patch on top of the GCC 10.1.0 tarball. Sadly, it still fails with the same error. It looks like ZSTD_CPPFLAGS is not actually exported/set anywhere (only available in configure), which is why I made use of ZSTD_INCLUDE.
Comment 3 Martin Liška 2020-05-11 09:31:45 UTC
(In reply to Michael Kuhn from comment #2)
> (In reply to Martin Liška from comment #1)
> > Thank you for the bug report.
> > I'm sending a better patch, can you please test it?
> 
> I applied your patch on top of the GCC 10.1.0 tarball. Sadly, it still fails
> with the same error. It looks like ZSTD_CPPFLAGS is not actually
> exported/set anywhere (only available in configure), which is why I made use
> of ZSTD_INCLUDE.

You are right! It should be actually added to CXXFLAGS that are not respected in gcc/Makefile:
https://github.com/gcc-mirror/gcc/blob/master/gcc/configure.ac#L1380

I'm investigating that.
Comment 4 Martin Liška 2020-05-11 09:49:17 UTC
Hm, I must say that current master works for me:

$ ../configure --with-zstd=/tmp/sparta
...
$ make lto-compress.o
g++ -fno-PIE -c  -I/home/marxin/Programming/gcc/gcc/../zlib -g  -I/tmp/sparta/include -DIN_GCC     -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -I. -I. -I/home/marxin/Programming/gcc/gcc -I/home/marxin/Programming/gcc/gcc/. -I/home/marxin/Programming/gcc/gcc/../include -I/home/marxin/Programming/gcc/gcc/../libcpp/include  -I/home/marxin/Programming/gcc/gcc/../libdecnumber -I/home/marxin/Programming/gcc/gcc/../libdecnumber/bid -I../libdecnumber -I/home/marxin/Programming/gcc/gcc/../libbacktrace   -o lto-compress.o -MT lto-compress.o -MMD -MP -MF ./.deps/lto-compress.TPo /home/marxin/Programming/gcc/gcc/lto-compress.c

you can find "-I/tmp/sparta/include" at the command line.
Comment 5 Michael Kuhn 2020-05-12 10:49:46 UTC
Created attachment 48516 [details]
Updated zstd patch

Thanks for investigating! Sadly, this still does not work for me, even with master.
If I do "make lto-compress.o" in the gcc subdirectory, it works (and includes the include path), but a normal "make" in the build directory does not.

In Spack, another issue has come up: When building with Clang (as frequently done on macOS), libzstd cannot be found. After some investigation, it seems that the library path is also not set correctly.

I have come up with the attached updated patch that allows me build GCC with zstd in a non-standard path. It is also a bit cleaner than the previous approach.
Comment 6 Martin Liška 2020-05-13 13:26:34 UTC
I support the patch. Can you please send it to gcc-patches mailing list?
Comment 7 Michael Kuhn 2020-05-20 19:35:11 UTC
Took me a while, sorry. I have just sent the patch to the list.
Comment 8 Eric Gallager 2020-05-20 22:29:55 UTC
(In reply to Michael Kuhn from comment #7)
> Took me a while, sorry. I have just sent the patch to the list.

for reference, that patch is here: https://gcc.gnu.org/pipermail/gcc-patches/2020-May/546179.html
Comment 9 Eric Gallager 2021-05-04 16:48:19 UTC
(In reply to Eric Gallager from comment #8)
> (In reply to Michael Kuhn from comment #7)
> > Took me a while, sorry. I have just sent the patch to the list.
> 
> for reference, that patch is here:
> https://gcc.gnu.org/pipermail/gcc-patches/2020-May/546179.html

Er wait is that what caused me to become the assignee for this? I was just linking to Michael's patch; it's not actually my own patch... changing assignee to him...