Bug 513825 - missing i686-pc-mingw32-pkg-config
Summary: missing i686-pc-mingw32-pkg-config
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: mingw32-glib2
Version: 11
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Richard W.M. Jones
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 513824 513826
TreeView+ depends on / blocked
 
Reported: 2009-07-26 11:45 UTC by Paolo Bonzini
Modified: 2009-08-29 14:37 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-08-29 14:37:04 UTC


Attachments (Terms of Use)

Description Paolo Bonzini 2009-07-26 11:45:44 UTC
(Reported here for lack of a better place).

Description of problem:
When compiling a program that uses glib, the host pkg-config program is used, and this might cause the version numbers in the library to have a mismatch with the mingw version of glib.

Luckily, pkg-config is a *tool*, so it is first searched prefixed with $host.  It is enough to put this script in /usr/bin/i686-pc-mingw32-pkg-config then:

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

How reproducible:
You must have the latest F11 glib (2.20.4) installed, since mingw-glib2 is still at 2.20.1.

Steps to reproduce:
1. Add c:\mingw links as explained in bug 513819
2. Install a touch program as explained in bug 513824
3. Try configure script in bug 513819 (./configure --host=i686-pc-mingw32)

Actual result:
The script diagnoses a version mismatch

Expected result:
The script should work.

Additional info:
This bug and bug 513824, if fixed, would allow to compile glib programs without --disable-glibtest.  Fixing bug 513819 however is enough to actually *run* crosscompiled glib/gtk programs.

A similar bug applies to other packages with an independent -config script, such as sdl.  That is more problematic because sdl-config is searched as a program, not as a tool.  Still, installing i686-pc-mingw32-sdl-config would at least allow the user to specify it manually with the SDL_CONFIG environment variable.

Comment 1 Paolo Bonzini 2009-07-26 12:00:30 UTC
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 "$@"

Comment 2 Erik van Pienbroek 2009-07-26 16:26:21 UTC
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

Comment 3 Richard W.M. Jones 2009-07-26 17:58:27 UTC
As Erik says, the correct way is to use /usr/bin/mingw32-pkg-config.

Comment 4 Paolo Bonzini 2009-07-26 18:23:31 UTC
[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

Comment 5 Erik van Pienbroek 2009-07-27 08:01:36 UTC
(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

Comment 6 Paolo Bonzini 2009-07-27 08:23:33 UTC
> 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.

Comment 7 Richard W.M. Jones 2009-07-27 08:42:08 UTC
> > 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.

Comment 8 Levente Farkas 2009-07-27 08:47:59 UTC
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?

Comment 9 Erik van Pienbroek 2009-07-27 09:52:06 UTC
(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

Comment 10 Erik van Pienbroek 2009-08-29 14:37:04 UTC
The tool i686-pc-mingw32-pkg-config was just added to mingw32-filesystem-54.1 in F12/rawhide


Note You need to log in before you can comment on or make changes to this bug.