Bug 513826

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.

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

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.

(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.

Created attachment 355373 [details]
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}.

-%_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.

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-libjpeg.spec?view=markup (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..

> 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.

> > (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.

Please discuss packaging problems on the list.
Closing as NOTABUG.