Exporting PKG_CONFIG_PATH in %___build_pre_env breaks cross compilation

[LMattsson]

Describe the bug
I am unable to build arm rpms on an x86_64 system, unless I manually add a workaround in the spec file.

The x86_64 system has a standard cross compilation environment set up, and I have previously been able to build arm rpms on it (using rpm v. 4.9).

After upgrading to rpm v. 4.18.2, I got errors when trying to build an arm rpm, since it was using the system's pc-files rather than arm specific pc-files. When adding unset PKG_CONFIG_PATH directly after %build in my spec file, I could build the arm rpm successfully.

I believe the issue is caused by these lines in macros.in, that sets and exports PKG_CONFIG_PATH. This export is present in newer rpm versions as well.

To Reproduce

1. Have an arm cross compilation environment set up on an x86_64 system
2. Run rpmbuild --target=armv7hl. The build should fail.
3. When checking the log, some CFLAGS variables may have missing values or wrong values. Below are the ones I noticed.

# Missing value
OPENSSL_CFLAGS:                  
# Using x86_64 path instead of "/usr/arm-none-linux-gnueabi/sys-root/..."
GIO2_CFLAGS:             -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include 

4. Due to those variables being faulty, I got the following error at the end of my log file:
   /usr/lib/libstdc++.so: error adding symbols: File in wrong format

Expected behavior
I believe that the pc-files for the corresponding architecture should be used when cross compiling, without having to unset PKG_CONFIG_PATH.

Environment

• OS / Distribution: Fedora 39
• Version: Issue seen with rpm-4.18.2, but should still be present in rpm-4.19

Additional context
Links to original commit and to the bug report that looks like the main reason PKG_CONFIG_PATH was added.

To me, it seems like the reason for adding this was to simplify cross compilation. While setting PKG_CONFIG_PATH does make it simpler for cross compilation between x86_64 and i386, there are still manual steps that have to be done to get the cross compilation fully working between those two platforms.

In my opinion, automating one of the manual steps for one type of cross compilation does not seem like it is worth the drawback of having other types of cross compilation breaking.