Actually this is the right way to set the library paths:

#! /bin/sh
prefix=`i686-pc-mingw32-gcc --print-sysroot`/mingw
PKG_CONFIG_LIBDIR=$prefix/lib/pkgconfig:$prefix/share/pkgconfig
export PKG_CONFIG_LIBDIR
exec pkg-config "$@"

We already have a small wrapper script for pkg-config which sets the right environment variables: /usr/bin/mingw32-pkg-config (part of mingw32-filesystem).

There are also some other wrapper scripts in that package which can aid people in cross-compiling packages for the mingw32 target: /usr/bin/mingw32-configure, /usr/bin/mingw32-make and /usr/bin/mingw32-cmake

As Erik says, the correct way is to use /usr/bin/mingw32-pkg-config.

[Warning: long comment ahead].

The naming however is crucial in this case.  mingw32-pkg-config is not a convenience for the user, like the configure/make scripts; it is a host-specific tool that (only by virtue of pkg-config's configurability) happens to share its executable with the native tool.

The key point is that it is not invoked by the user, rather it is meant to be found by its clients' build system.  The autotools were designed from the start to support host-specific tools in a cross-compilation scenario <rant>*not* by defining a zillion variables differently for each cross-compilation setup, but rather</rant> just by naming the tools correctly and passing --host.


Now, this bug is indeed strictly connected to the wrapper scripts.   You (we?) should be careful to distinguish the cases in which the configure/make wrapper scripts are working around bugs in Fedora's packaging; this is one of them.

Rather, the wrapper scripts are useful to work around bugs in the program's build system (as in the sdl-config case); they should never be *necessary*.  In particular, this should be the way to build a program, from preferred to least preferred:

1) "../configure --host=i686-pc-mingw32 && make".  The kosher way.

2) "mingw32-configure && make" or "mingw32-configure && mingw32-make" for programs with a handwritten configure script (though these probably would not accept all the arguments passed by mingw32-configure).

3) "mingw32-make" for programs that do not use autotools (crossing your fingers).

I say this because the configure and make script in my opinion are actually doing some inappropriate things.  Some of them might be good in an automated build system (RPM), but maybe not for a casual user who wants to cross-compile his favorite package and for a developer who wants to develop a Windows port using mingw32.  Others are actively wrong.  In particular:

1) mingw32-make sets an HOST_CC variable.  This is wrong, since it is referring to the *build* system and not the *host*, and should not be used for programs that use an autoconf configure.  The autotools were designed to support a three system cross (build/host/target); the HOST_CC variable comes probably from the Linux kernel and you don't care for Windows cross compilation.

2a) compiling everything with -Wp,-D_FORTIFY_SOURCE=2 is not in general something that should be done by a casual user.  Some programs (it's their fault, granted) stop working.  It should be okay for a distribution in which there is complete control on testing and a quality assurance process, but it should not be passed automatically for the user.

2b) Passing -fexceptions for the Windows C compiler is useless, especially before the MinGW compiler is switched to dwarf-2 exceptions.  But in any case, the MinGW runtime is not advanced enough (unlike glibc) to take any advantage of -fexceptions.

2c) passing -mms-bitfields also has serious binary compatibility problems.  Either gcc/config/i386/cygming.h should be patched in GCC to make this the default, or it should not be passed.

3) the cache file was disabled for a reason in Autoconf 2.50 (ten years ago approx.).  A developer has to remove manually the cache file whenever he rebuilds the configure script.  Keeping it is okay for RPM, but absolutely not for a developer (and the nonstandard name mingw32-config.cache adds to the confusion).

4) passing the same variables twice (first to configure and then to make) is useless.  That's why I said that even "mingw32-configure && make" ought to be enough.


I can file separate bugs for 1, 2a and 2c, since they affect also the building of Fedora packages.

The only strictly necessary part of mingw-configure is this:

  for i in `ls /usr/i686-pc-mingw32/sys-root/mingw/bin/*|grep -- "-config$"` ; do 
    x=`basename $i|tr "a-z+-" "A-ZX_"`; 
    declare -x $x="$i" ; export $x; 
  done; 

One way to do so without requiring an external wrapper script could have been to add a /etc/profile.d script doing "export CONFIG_SITE=/etc/config.site", and then something like this:

- in /etc/config.site (provided by a fundamental .noarch package; not autoconf or gcc or glibc-devel!)

  for i in /etc/config.site.d/*; do . $i; done

- in /etc/config.site.d/mingw (provided by mingw-filesystem)

  case $host in
    *mingw* )
      for i in `ls /usr/i686-pc-mingw32/sys-root/mingw/bin/*|grep -- "-config$"`
      do 
        x=`basename $i|tr "a-z+-" "A-ZX_"`; 
        declare -x $x="$i" ; export $x; 
      done;;
  esac

(In reply to comment #4)
> [Warning: long comment ahead].
> 
> The naming however is crucial in this case.  mingw32-pkg-config is not a
> convenience for the user, like the configure/make scripts; it is a
> host-specific tool that (only by virtue of pkg-config's configurability)
> happens to share its executable with the native tool.
> 
> The key point is that it is not invoked by the user, rather it is meant to be
> found by its clients' build system.  The autotools were designed from the start
> to support host-specific tools in a cross-compilation scenario <rant>*not* by
> defining a zillion variables differently for each cross-compilation setup, but
> rather</rant> just by naming the tools correctly and passing --host.

I'm starting to get your point. The mingw32-pkg-config tool should really be renamed to i686-pc-mingw32-pkg-config so it can be found by ./configure scripts without manually fiddling the environment variables. We can do such a change without any side effects. However, if we want to use the sysroot part as mentioned in bug 513826 we need to perform a complete rebuild of all mingw32 packages. Such a rebuild should be prepared by determining the order in which packages need to be rebuild. In rawhide, the mass rebuild of all packages has just been started this weekend so I don't know if it's okay to do such another rebuild right now. Additionally, every package which produces .pc files needs to manually 'fix' these to have the right sysroot set (which is more or less a packaging guidelines adjustment).

Another issue I'm afraid of is that binaries compiled using Fedora's i686-pc-mingw32-gcc can't be mixed with binaries compiled with MinGW's GCC running in a wine environment (or that strange side-effects are introduced, possible due to bugs in wine)

> 1) mingw32-make sets an HOST_CC variable.  This is wrong, since it is referring
> to the *build* system and not the *host*, and should not be used for programs
> that use an autoconf configure.  The autotools were designed to support a three
> system cross (build/host/target); the HOST_CC variable comes probably from the
> Linux kernel and you don't care for Windows cross compilation.

I'm also having doubts whether the HOST_CC variable is really necessary. Perhaps Richard can remember the reason why it was there in the first place?

> 2a) compiling everything with -Wp,-D_FORTIFY_SOURCE=2 is not in general
> something that should be done by a casual user.  Some programs (it's their
> fault, granted) stop working.  It should be okay for a distribution in which
> there is complete control on testing and a quality assurance process, but it
> should not be passed automatically for the user.

I think of FORTIFY_SOURCE as an aid to detect bugs in libraries/programs. I can't think of any reason why this feature should be dropped.

> 2b) Passing -fexceptions for the Windows C compiler is useless, especially
> before the MinGW compiler is switched to dwarf-2 exceptions.  But in any case,
> the MinGW runtime is not advanced enough (unlike glibc) to take any advantage
> of -fexceptions.

We already have a bug open WRT exception handling in MinGW: 489100
I'm not familiar with exception handling in GCC so I refrain myself from further comments on this.

> 2c) passing -mms-bitfields also has serious binary compatibility problems. 
> Either gcc/config/i386/cygming.h should be patched in GCC to make this the
> default, or it should not be passed.

IIRC, this parameter has became on by default in recent versions of GCC (I don't have a link to confirm it right now).

> 3) the cache file was disabled for a reason in Autoconf 2.50 (ten years ago
> approx.).  A developer has to remove manually the cache file whenever he
> rebuilds the configure script.  Keeping it is okay for RPM, but absolutely not
> for a developer (and the nonstandard name mingw32-config.cache adds to the
> confusion).

The cache file is only really needed for the glib2 package because some ./configure runtime checks are really required

> 4) passing the same variables twice (first to configure and then to make) is
> useless.  That's why I said that even "mingw32-configure && make" ought to be
> enough.

Yeah, mingw32-make shouldn't be used by anything. mingw32-configure && make should be enough for almost all cases

> I'm starting to get your point. The mingw32-pkg-config tool should really be
> renamed to i686-pc-mingw32-pkg-config so it can be found by ./configure 
> scripts without manually fiddling the environment variables. We can do such a 
> change without any side effects. However, if we want to use the sysroot part 
> as mentioned in bug 513826 we need to perform a complete rebuild of all 
> mingw32 packages.

Yes, that's why I filed a separate bug.

> Another issue I'm afraid of is that binaries compiled using Fedora's
> i686-pc-mingw32-gcc can't be mixed with binaries compiled with MinGW's GCC
> running in a wine environment (or that strange side-effects are introduced,
> possible due to bugs in wine)

That would be a bug.  One more reason to try what I'm doing. :-)

> I think of FORTIFY_SOURCE as an aid to detect bugs in libraries/programs. I
> can't think of any reason why this feature should be dropped.

Fine by me.

> > 2c) passing -mms-bitfields also has serious binary compatibility problems. 
> 
> IIRC, this parameter has became on by default in recent versions of GCC (I
> don't have a link to confirm it right now).

Unfortunately I checked the upstream sources and it's not.

> The cache file is only really needed for the glib2 package because some
> ./configure runtime checks are really required

You should use CONFIG_SITE for this too.

> > 1) mingw32-make sets an HOST_CC variable.  This is wrong, since it is referring
> > to the *build* system and not the *host*, and should not be used for programs
> > that use an autoconf configure.  The autotools were designed to support a three
> > system cross (build/host/target); the HOST_CC variable comes probably from the
> > Linux kernel and you don't care for Windows cross compilation.
> 
> I'm also having doubts whether the HOST_CC variable is really necessary.
> Perhaps Richard can remember the reason why it was there in the first place?

I've never wanted or supported having 'mingw32-make'.  It was
Levente Farkas's idea, and a terrible one at that.  This script
should be removed entirely.

the reason for mingw32-make is that not all package use autoconf/automake and in that case this is a useful helper scipts. and those who wouldn't like to use it don't use. why bother it anyone?

(In reply to comment #7)
> > I'm also having doubts whether the HOST_CC variable is really necessary.
> > Perhaps Richard can remember the reason why it was there in the first place?
> 
> I've never wanted or supported having 'mingw32-make'.  It was
> Levente Farkas's idea, and a terrible one at that.  This script
> should be removed entirely.  

The HOST_CC variable is set in /etc/rpm/macros.mingw32 and used for all our mingw32-* wrapper scripts

The tool i686-pc-mingw32-pkg-config was just added to mingw32-filesystem-54.1 in F12/rawhide