[Bug 513826] New: .pc files for mingw32 library include the sysroot

[Red Hat Bugzilla]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.

Summary: .pc files for mingw32 library include the sysroot

https://bugzilla.redhat.com/show_bug.cgi?id=513826

Summary: .pc files for mingw32 library include the sysroot
           Product: Fedora
           Version: 11
          Platform: All
        OS/Version: Linux
            Status: NEW
          Severity: medium
          Priority: low
         Component: mingw32-glib2
        AssignedTo: [e-mail]
        ReportedBy: [e-mail]
         QAContact: [e-mail]
                CC: [e-mail], [e-mail],
                    [e-mail], [e-mail],
                    [e-mail]
        Depends on: 513825
    Classification: Fedora
    Target Release: ---

Description of problem:
The paths in the .pc files for mingw32 include the
/usr/i686-pc-mingw32/sys-root component.  This would prevent using them within
the MSYS shell, for example.

It would be more correct to install them without the path and, in a
i686-pc-mingw32-pkg-config (see bug 513825), provide the PKG_CONFIG_SYSROOT_DIR
variable.  The script would work like this then:

#! /bin/sh

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

[Bug 513826] .pc files for mingw32 library include the sysroot

[Red Hat Bugzilla]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.

https://bugzilla.redhat.com/show_bug.cgi?id=513826

--- Comment #1 from Paolo Bonzini   2009-07-26 15:15:36 EDT ---
To clarify: the paths work, but still they are not correct.  Right now if I
want to install MSYS under Wine I have two choices:

1) I proceed as in bug 513819 so that the Fedora mingw root is visible under
MSYS.  Then however I cannot use pkg-config under MSYS.

2) I copy everything from /usr/i686-pc-mingw32/sys-root/mingw under Wine's
c:/mingw, and then I lose all the updates that come through Fedora's package
manager.  I also have to update the .pc files manually.

It's a lose-lose situation, and PKG_CONFIG_SYSROOT_DIR was meant exactly to
support this.

[Bug 513826] .pc files for mingw32 library include the sysroot

[Red Hat Bugzilla]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.

https://bugzilla.redhat.com/show_bug.cgi?id=513826

Erik van Pienbroek  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #2 from Erik van Pienbroek   2009-07-26 18:20:13 EDT ---
Why would you want to install MSYS under Wine? MSYS just provides some tools
which we already have native on Linux. The bash/sh from MSYS is also way slower
than native bash/sh

[Bug 513826] .pc files for mingw32 library include the sysroot

[Red Hat Bugzilla]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.

https://bugzilla.redhat.com/show_bug.cgi?id=513826

--- Comment #3 from Paolo Bonzini   2009-07-27 03:05:30 EDT ---
For testing.  I want to make sure that there are no hidden bits in the
configure/make files that *only* work when crosscompiling (the typical example
is forgetting to quote a variable that could contain Windows \ paths).

Besides, the idea of a sysroot is to match *exactly* what would be on the
non-native system.  I could take the Fedora sysroot and copy it to a real
Windows machine, and it should just work.  Now instead if I do this and install
the Windows version of pkg-config, it will not work because the .pc files
contains pointers to the Fedora images.

This is not easy to fix (it is a "flag day" bug, you have to fix all packages
at once), so it may not have a high priority.  But it is serious.

[Bug 513826] .pc files for mingw32 library include the sysroot

[Red Hat Bugzilla]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.

https://bugzilla.redhat.com/show_bug.cgi?id=513826

--- Comment #4 from Richard W.M. Jones   2009-07-27 04:53:55 EDT ---
(In reply to comment #3)
> For testing.  I want to make sure that there are no hidden bits in the
> configure/make files that *only* work when crosscompiling (the typical example
> is forgetting to quote a variable that could contain Windows \ paths).
>
> Besides, the idea of a sysroot is to match *exactly* what would be on the
> non-native system.  I could take the Fedora sysroot and copy it to a real
> Windows machine, and it should just work.  Now instead if I do this and install
> the Windows version of pkg-config, it will not work because the .pc files
> contains pointers to the Fedora images.

This isn't how we install on Windows at all.  We use NSIS to
build installers.

And the aim of this project is to free developers from having to
use Windows at all, not to allow people to copy binaries onto a
Windows machine and continue development there.

The *.pc files contain the correct paths for cross-compiling
to a Windows host from a Fedora build system, which is precisely
the aim of this project.

[Bug 513826] .pc files for mingw32 library include the sysroot

[Red Hat Bugzilla]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.

https://bugzilla.redhat.com/show_bug.cgi?id=513826

--- Comment #5 from Paolo Bonzini   2009-07-28 04:36:53 EDT ---
Created an attachment (id=355373)
 --> (https://bugzilla.redhat.com/attachment.cgi?id=355373)
redhat-rpm-config part of the patch

The remaining part is to change the packages to do a change similar to what the
patch does to %{_mingw32_makeinstall}.

[Bug 513826] .pc files for mingw32 library include the sysroot

[Red Hat Bugzilla]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.

https://bugzilla.redhat.com/show_bug.cgi?id=513826

Paolo Bonzini  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
         Depends on|                            |514187

[Bug 513826] .pc files for mingw32 library include the sysroot

[Red Hat Bugzilla]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.

https://bugzilla.redhat.com/show_bug.cgi?id=513826

--- Comment #6 from Richard W.M. Jones   2009-07-28 04:46:57 EDT ---
-%_mingw32_prefix          %{_mingw32_sysroot}/mingw
+%_mingw32_prefix          /mingw

I'm not sure if this proposal is serious or not, but
it would completely break every package in the repository.

Also, setting DESTDIR in make install is wrong.  DESTDIR
should be left to the packager to use.

[Bug 513826] .pc files for mingw32 library include the sysroot

[Red Hat Bugzilla]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.

https://bugzilla.redhat.com/show_bug.cgi?id=513826

Paolo Bonzini  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|                            |514187
         Depends on|514187                      |

[Bug 513826] .pc files for mingw32 library include the sysroot

[Red Hat Bugzilla]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.

https://bugzilla.redhat.com/show_bug.cgi?id=513826

--- Comment #7 from Erik van Pienbroek   2009-07-28 04:59:31 EDT ---
This isn't going to work.. The _mingw32_makeinstall change breaks the only user
of it, mingw32-libjpeg:
http://cvs.fedoraproject.org/viewvc/rpms/mingw32-libjpeg/devel/mingw32-libjp...
(because of it's broken build system).

Additionally, all packages now get installed in /mingw as Richard already
mentioned (to work around that another change is required in the
mingw32_configure macro). The DESTDIR change is really useless as it will be
overridden by all .spec files anyway (where 'make install
DESTDIR=$RPM_BUILD_ROOT' is used).

What is it that you want to archieve with these changes? All that it causes is
mass-breakage with no benefit in the end..

[Bug 513826] .pc files for mingw32 library include the sysroot

[Red Hat Bugzilla]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.

https://bugzilla.redhat.com/show_bug.cgi?id=513826

--- Comment #8 from Paolo Bonzini   2009-07-28 05:14:09 EDT ---
> I'm not sure if this proposal is serious or not, but
> it would completely break every package in the repository.

I'm sure we agreed that this bug, if it is fixed, would require changing every
package in the repository.
> (to work around that another change is required in the
> mingw32_configure macro).

No, this would be totally wrong!  The configure and make phases should use
exactly the same prefix that is used at run-time.
> What is it that you want to archieve with these changes? All that it causes is
> mass-breakage with no benefit in the end..

Many things.  For example, say I'm a developer that bundles Fedora's gtk+ DLLs
with his own binary.  I get a report that my binary distribution does not work
on Windows.  I have to see if it's a problem in my code or in Fedora's.  So I
take the Fedora sys-root, copy it to a real Windows machine, install MSYS and
try to build my package.  Except that this doesn't work because the Fedora
sys-root is not a sys-root (because it includes references to paths in the
cross-compilation environment), so this does not work

Or, avoiding that the *Windows* binaries in the sysroot include references to
the /usr/i686-pc-mingw32/sys-root path.  This is equivalent to having the
mock-buildroot in a binary RPM, which is flagged by rpmlint as a serious error.

IOW, I admire a lot the mingw32 packages and they were a useful tool for me. 
But independent of whether they work, unfortunately they have some flaws that
are pretty fundamental and should be fixed.

[Bug 513826] .pc files for mingw32 library include the sysroot

[Red Hat Bugzilla]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.

https://bugzilla.redhat.com/show_bug.cgi?id=513826

--- Comment #9 from Erik van Pienbroek   2009-07-28 06:06:14 EDT ---
> > (to work around that another change is required in the
> > mingw32_configure macro).
>
> No, this would be totally wrong!  The configure and make phases should use
> exactly the same prefix that is used at run-time.

But we don't want to move all our packages from
/usr/i686-pc-mingw32/sys-root/mingw to /mingw as that's a violation of both the
packaging guidelines and the FHS/LSB so it's never going to be approved by the
packaging committee.

Autotools doesn't support sysroot's AFAIK so I think your idea isn't going to
work unless we move everything to /mingw (which isn't allowed) or heavily patch
all the libraries (which we won't do without a very strong motivation).
> > What is it that you want to archieve with these changes? All that it causes is
> > mass-breakage with no benefit in the end..
>
> Many things.  For example, say I'm a developer that bundles Fedora's gtk+ DLLs
> with his own binary.  I get a report that my binary distribution does not work
> on Windows.  I have to see if it's a problem in my code or in Fedora's.  So I
> take the Fedora sys-root, copy it to a real Windows machine, install MSYS and
> try to build my package.  Except that this doesn't work because the Fedora
> sys-root is not a sys-root (because it includes references to paths in the
> cross-compilation environment), so this does not work

Why would you want to rebuild your program in Wine/MSYS? A 'make && make
install' is much faster from a native Linux environment than Wine/MSYS and you
don't have the risk of introducing possible side effects (due to a
non-identical compiler).

I'm also a developer who is using the Fedora MinGW toolchain to create Win32
packages of my open source project for end-users. There are some tools which
I'm using to find and process errors, like Dr. MinGW.

Dr. MinGW consists of a small file called exchndl.dll. All the program needs to
do is LoadLibrary() it. Whenever a segfault/crash occurs in the program, a new
file will be created called name_of_program.rpt which contains a GDB backstrace
and some additional information. End-users which are encountering
segfaults/crashes can send this auto-generated file back to me (the developer)
so I can find out the cause (in the large majority of cases) and fix the bug
(all from a Linux host without using wine).

For the small number of cases which can't be solved this way GDB can be used.
However, GDB doesn't work really well with Wine so I'm forced to reboot to
Windows for those cases (which is like once every few weeks).

To test my Win32 projects I sometimes use Wine, but if I encounter a bug it's
frequently a dilemma: Is this bug caused by my program or Wine? While I'm
working on my projects I don't really have time to dig into Wine itself to
further research such cases so in that situation it's faster to reboot to
Windows anyway. (Yeah, I know that I'm not really helping the Wine project to
improve that way but my time to work on open source projects is limited too..)

To find out whether all the required DLL's are bundled in the installer I use
the dependency walker (depends.exe) which can be found at
http://www.dependencywalker.com/
This program can be used from Wine to analyse all the .DLL's which are required
by some .exe or .dll and whether one of them is missing.
> Or, avoiding that the *Windows* binaries in the sysroot include references to
> the /usr/i686-pc-mingw32/sys-root path.  This is equivalent to having the
> mock-buildroot in a binary RPM, which is flagged by rpmlint as a serious error.

Binaries (not scripts!) containing references to
/usr/i686-pc-mingw32/sys-root/mingw should be reported and fixed, but I guess
most of them are false positives anyway (like fallback-paths which will never
be used on Win32 environments).
> IOW, I admire a lot the mingw32 packages and they were a useful tool for me. 
> But independent of whether they work, unfortunately they have some flaws that
> are pretty fundamental and should be fixed.

Other then the mingw32-pkg-config -> i686-pc-mingw32-pkg-config rename I still
don't see any fundamental flaws. While wine is great for initial/basic testing,
I don't think of it as a stable environment for thorough debugging and testing
of applications.

[Bug 513826] .pc files for mingw32 library include the sysroot

[Red Hat Bugzilla]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.

https://bugzilla.redhat.com/show_bug.cgi?id=513826

Bug 513826 depends on bug 513825, which changed state.

Bug 513825 Summary: missing i686-pc-mingw32-pkg-config
https://bugzilla.redhat.com/show_bug.cgi?id=513825

What    |Old Value                   |New Value
----------------------------------------------------------------------------
             Status|NEW                         |CLOSED
         Resolution|                            |RAWHIDE

[Bug 513826] .pc files for mingw32 library include the sysroot

[Red Hat Bugzilla]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.

https://bugzilla.redhat.com/show_bug.cgi?id=513826

Richard W.M. Jones  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |CLOSED
         Resolution|                            |NOTABUG

--- Comment #10 from Richard W.M. Jones   2009-09-09 10:13:21 EDT ---
Please discuss packaging problems on the list.
Closing as NOTABUG.