5:06 a.m.
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 <erik-fedora(a)vanpienbroek.nl> 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.
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.