Bug 688171

Unfortunately this will break compilation of packages using RPM:
$ grep -Hr PKG_CONFIG /usr/lib/rpm/*
macros:  PKG_CONFIG_PATH=\"%{_libdir}/pkgconfig:%{_datadir}/pkgconfig\"\
macros:  export PKG_CONFIG_PATH\
pkgconfigdeps.sh:	export PKG_CONFIG_PATH="$DIR:$DIR/../../share/pkgconfig"
pkgconfigdeps.sh:	export PKG_CONFIG_PATH="$DIR:$DIR/../../share/pkgconfig"

The match in the macros file is part of the %___build_pre section (which will always get called in RPM %build sections)

If I change the mingw32-curl package to this:
 %build
+export > /tmp/rpm_export1
 %{_mingw32_configure} \
   --with-ssl --enable-ipv6 \
   --with-ca-bundle=%{_mingw32_sysconfdir}/pki/tls/certs/ca-bundle.crt \
   --with-libidn \
   --enable-static --with-libssh2 \
   --without-random
+export > /tmp/rpm_export2

Then the /tmp/rpm_export1 file will contain the line: export PKG_CONFIG_PATH="/usr/lib64/pkgconfig:/usr/share/pkgconfig" (set by the %___build_pre macro)
The /tmp/rpm_export2 file doesn't have the PKG_CONFIG_PATH export as the %{_mingw32_configure} call (thus %{_mingw32_env}) has replaced it with: export PKG_CONFIG_LIBDIR="/usr/i686-w64-mingw32/sys-root/mingw/lib/pkgconfig" (which is what we want to avoid pulling in native stuff)

A possible solution to your issue would be that a new variable like MINGW32_PKG_CONFIG_PATH gets introduced. When it's set, we won't unset the PKG_CONFIG_PATH, but set the PKG_CONFIG_PATH to the value of that MINGW32_PKG_CONFIG_PATH variable. So with this, you could do something like:

MINGW32_PKG_CONFIG_PATH=/opt/my_custom_prefix/lib/pkgconfig pkg-config --cflags glib-2.0

How do the other Fedora MinGW maintainers think of such a change?

Appears that MINGW32_PKG_CONFIG_PATH is a good practical
solution.  Does it fit the reporter's need?

(In reply to comment #1)
> Unfortunately this will break compilation of packages using RPM:

Not necessarily.

The way i686-pc-mingw32-* wrapper scripts are currently done is that they internally evaluate the matching rpm macro. For example, i686-pc-mingw32-pkg-config runs 'rpm --eval %{_mingw32_pkg_config}'.

We need the unset command in the rpm macro, but it's not needed for the wrapper script. In fact, it's not only unneeded but might cause problems when configure scripts call <host-triplet>-pkg-config.

I would say another solution is rewriting i686-pc-mingw32-pkg-config script so it wouldn't call rpm --eval internally. With that we'd be able to get rid of the 'unset' command in the script, but keep it in the rpm macro.

What about filtering the contents of PKG_CONFIG_PATH for bad directories instead of unsetting it entirely? It's more code, of course, but it'd work better.

(In reply to comment #3)
> We need the unset command in the rpm macro, but it's not needed for the wrapper
> script. In fact, it's not only unneeded but might cause problems when configure
> scripts call <host-triplet>-pkg-config.
> 
> I would say another solution is rewriting i686-pc-mingw32-pkg-config script so
> it wouldn't call rpm --eval internally. With that we'd be able to get rid of
> the 'unset' command in the script, but keep it in the rpm macro.

Why not just remove the "unset PKG_CONFIG_PATH" from %_mingw32_pkg_config but leave it in %_mingw32_env?  That way PKG_CONFIG_PATH will still be honoured when building manually, such as the OP's example, but will be ignored when building RPMs.

That sounds like a good solution.
Here's a proposed patch:

--- a/macros.mingw32
+++ b/macros.mingw32
@@ -97,9 +97,7 @@ package or when debugging this package.\
   unset x i
 
 %_mingw32_pkg_config \
-  PKG_CONFIG_LIBDIR="%{_mingw32_libdir}/pkgconfig"; export PKG_CONFIG_LIBDIR; \
-  unset PKG_CONFIG_PATH; \
-  pkg-config
+  PKG_CONFIG_LIBDIR="%{_mingw32_libdir}/pkgconfig" pkg-config
 
 %_mingw32_configure %{_mingw32_env} ; \
   __mingw32_topdir=.; if ! test -x configure; then __mingw32_topdir=..; fi; \\\

The %_mingw32_env macro still has the unset PKG_CONFIG_PATH, but it shouldn't be called when one calls the script 'mingw32-pkg-config' or 'i686-pc-mingw32-pkg-config'.

Is the patch good enough to commit?

+1, yes please :)

+1, looks good.

mingw32-filesystem-67-1.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/mingw32-filesystem-67-1.fc15

Package mingw32-filesystem-67-1.fc15:
* should fix your issue,
* was pushed to the Fedora 15 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing mingw32-filesystem-67-1.fc15'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/mingw32-filesystem-67-1.fc15
then log in and leave karma (feedback).

mingw32-filesystem-67-1.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.