@pinskia wrote in https://forge.sourceware.org/gcc/gcc/pulls/248#issuecomment-7817:
> Just to make sure you have tested the following: > > 1. standard GCC bootstrap (on any target) with and without the > --with-zstd? > > 2. a cross compile with and without --with-zstd option? > > 3. a candian cross with and without --with-zstd option? including the > auto option; actually how does pkg-config work in this case? > > > I am mostly worried about 3 here because that auto might use the wrong > library and things go down hill from there. Thanks for the review Andrea! config/zstd.m4 already used pkg-config to detect zstd before my changes, and binutils uses that macro today. My changes aim to unify zstd detection by making GCC and libbacktrace use the same shared macro. I tested the following configurations, each with the zstd option omitted (--with-zstd), --with-zstd=yes, --with-zstd=no, and --with-zstd=auto: 1. Native x86_64-linux-gnu bootstrap. 2. Cross build with --target=aarch64-linux-gnu. 3. Canadian cross with --build=x86_64-linux-gnu, --host=aarch64-linux-gnu and --target=arm-none-eabi. All combinations passed, with zstd enabled for omitted/yes/auto and disabled for no. For the Canadian cross, I cleared PKG_CONFIG_PATH and set PKG_CONFIG_LIBDIR to point pkg-config to an AArch64 build of zstd. I verified that the resulting GCC executables were AArch64 binaries and contained zstd symbols in the enabled cases, but not with --with-zstd=no. Cross builds can use the default pkg-config configuration, whereas Canadian cross builds must configure it for host libraries. I also verified native non-bootstrap builds with --with-zstd=PATH pointing to static-only, shared-only, and combined static/shared zstd installations. One difference between current GCC trunk behavior and my patches is that trunk uses the compiler to find a suitable library. If you think this is important, I can give it a try to have that as a fallback in case pkg-config either does not find any candidate, or the candidate does not match the host. This would somewhat preserve the current behavior of GCC, but the down side is that it will make the macro more complex, but maybe it's worth it. WDYT? -- https://forge.sourceware.org/gcc/gcc/pulls/248#issuecomment-7826
