hi, while i try to rebuild mingw32 packages for rhel-6 i've got some problem with autoprovides somewhere. in fedora mingw32-gettext-0.18.1.1-1.fc16.noarch.rpm provides: ------------------------------- mingw32(libasprintf-0.dll) mingw32(libgettextlib-0-18-1.dll) mingw32(libgettextpo-0.dll) mingw32(libgettextsrc-0-18-1.dll) mingw32(libintl-8.dll) mingw32-gettext = 0.18.1.1-1.fc16 ------------------------------- while if i rebuild it, i've got this ------------------------------- libtool(/usr/i686-pc-mingw32/sys-root/mingw/lib/libasprintf.la) libtool(/usr/i686-pc-mingw32/sys-root/mingw/lib/libgettextlib.la) libtool(/usr/i686-pc-mingw32/sys-root/mingw/lib/libgettextpo.la) libtool(/usr/i686-pc-mingw32/sys-root/mingw/lib/libgettextsrc.la) libtool(/usr/i686-pc-mingw32/sys-root/mingw/lib/libintl.la) mingw32-gettext = 0.18.1.1-1.el6.1 ------------------------------- the real strange thing if i rebuild mingw32-gettext-0.17-15.fc15 on my system i've got the good (first) result (so i assume the problem is not i mingw32-filesystem). so it seems my repo sometimes give a good result sometimes not:-( and the same happened with mingw32-gcc-c++ too. anybody has any tip?
On 06/01/2011 08:47 AM, Farkas Levente wrote:
hi, while i try to rebuild mingw32 packages for rhel-6 i've got some problem with autoprovides somewhere. in fedora mingw32-gettext-0.18.1.1-1.fc16.noarch.rpm provides:
mingw32(libasprintf-0.dll) mingw32(libgettextlib-0-18-1.dll) mingw32(libgettextpo-0.dll) mingw32(libgettextsrc-0-18-1.dll) mingw32(libintl-8.dll) mingw32-gettext = 0.18.1.1-1.fc16
while if i rebuild it, i've got this
libtool(/usr/i686-pc-mingw32/sys-root/mingw/lib/libasprintf.la) libtool(/usr/i686-pc-mingw32/sys-root/mingw/lib/libgettextlib.la) libtool(/usr/i686-pc-mingw32/sys-root/mingw/lib/libgettextpo.la) libtool(/usr/i686-pc-mingw32/sys-root/mingw/lib/libgettextsrc.la) libtool(/usr/i686-pc-mingw32/sys-root/mingw/lib/libintl.la) mingw32-gettext = 0.18.1.1-1.el6.1
the real strange thing if i rebuild mingw32-gettext-0.17-15.fc15 on my system i've got the good (first) result (so i assume the problem is not i mingw32-filesystem). so it seems my repo sometimes give a good result sometimes not:-( and the same happened with mingw32-gcc-c++ too. anybody has any tip?
this problems getting more serious for me since the same happened with gcc too where the mingw32(libstdc++-6.dll) provides missing: ------------------------------------ [robot@buildsys i386]$ rpm -qpl --provides mingw32-gcc-c++-4.5.3-3.fc16.i686.rpm |grep libstdc mingw32(libstdc++-6.dll) /usr/i686-pc-mingw32/sys-root/mingw/bin/libstdc++-6.dll /usr/lib/gcc/i686-pc-mingw32/4.5.3/libstdc++.a /usr/lib/gcc/i686-pc-mingw32/4.5.3/libstdc++.dll.a /usr/lib/gcc/i686-pc-mingw32/4.5.3/libstdc++.dll.a-gdb.py [robot@buildsys i386]$ rpm -qpl --provides mingw32-gcc-c++-4.5.3-3.el6.i686.rpm|grep libstdc /usr/i686-pc-mingw32/sys-root/mingw/bin/libstdc++-6.dll /usr/lib/gcc/i686-pc-mingw32/4.5.3/libstdc++.a /usr/lib/gcc/i686-pc-mingw32/4.5.3/libstdc++.dll.a /usr/lib/gcc/i686-pc-mingw32/4.5.3/libstdc++.dll.a-gdb.py ------------------------------------ anyone who wrote the autoprovides? any tip? thanks.
Hi Farkas,
First of all, do you mind if I ask why you are locally replacing the gcc and binutils packages on RHEL 6 with the ones from Rawhide?
Andrew Beekhof put in a lot of effort to make the RHEL 6 mingw32 packages as stable as possible. Do you have any specific concerns with the RHEL 6 packages which makes them unusable for you?
I would really like to encourage you to collaborate on either EPEL or Fedora packages, instead of doing your own private fork.
On 06/01/2011 09:47 AM, Farkas Levente wrote:
hi, while i try to rebuild mingw32 packages for rhel-6 i've got some problem with autoprovides somewhere.
[...]
the real strange thing if i rebuild mingw32-gettext-0.17-15.fc15 on my system i've got the good (first) result (so i assume the problem is not i mingw32-filesystem). so it seems my repo sometimes give a good result sometimes not:-( and the same happened with mingw32-gcc-c++ too. anybody has any tip?
In general, I would suggest to pick either F13, F14, or F15 packages if you want to rebuild them in RHEL. Rawhide packages can often be in flux; having unstable packages is often not desired in a long term supported release like RHEL.
Having said that, the reason why mingw32-gettext and mingw32-gcc you took from Rawhide don't produce correct provides in RHEL is because they rely on RPM 4.9 features for dependency generation.
For example, mingw32-gcc used to have manual Provides in its spec file: -# We don't run the automatic dependency scripts which would -# normally detect and provide the following DLL: -Provides: mingw32(libstdc++-6.dll)
This is all now automatically generated with mingw32-filesystem 68 and RPM 4.9.
Hope this helps, Kalev
On 06/01/2011 06:38 PM, Kalev Lember wrote:
Hi Farkas,
First of all, do you mind if I ask why you are locally replacing the gcc and binutils packages on RHEL 6 with the ones from Rawhide?
Andrew Beekhof put in a lot of effort to make the RHEL 6 mingw32 packages as stable as possible. Do you have any specific concerns with the RHEL 6 packages which makes them unusable for you?
I would really like to encourage you to collaborate on either EPEL or Fedora packages, instead of doing your own private fork.
first we try that way. our final goal to create the _latest_ gstreamer packages with all of it's dependencies. unfortunately it's requires newer packages then the mingw32* in rhel-6.1 optional. and after we spend more then a day to try to update only specific packages which are older then gstreamer need and also try to rebuild binutils on 32 bit too (not to mention bz629209...) we give up. so now we try from the other end...
Having said that, the reason why mingw32-gettext and mingw32-gcc you took from Rawhide don't produce correct provides in RHEL is because they rely on RPM 4.9 features for dependency generation.
For example, mingw32-gcc used to have manual Provides in its spec file: -# We don't run the automatic dependency scripts which would -# normally detect and provide the following DLL: -Provides: mingw32(libstdc++-6.dll)
This is all now automatically generated with mingw32-filesystem 68 and RPM 4.9.
yes i already found it. even in this case if i've to modify mingw32-filesystem (ok i know i still has write access but wouldn't like to disturb) than i add some helper macro to macros.mingw32 something like this: ------------------------------ %_mingw32_pre_spec \ %if 0%{?rhel} <= 6 || 0%{?fedora} <= 15 \ %global __strip %{_mingw32_strip} \ %global __objdump %{_mingw32_objdump} \ %global _use_internal_dependency_generator 0 \ %global __find_requires %{_mingw32_findrequires} \ %global __find_provides %{_mingw32_findprovides} \ %define __debug_install_post %{_mingw32_debug_install_post} \ %endif ------------------------------ and start every spec file with: %{_mingw32_pre_spec} with this little overhead all spec file can work on both rhel and before fedora 16 and after fedora 16 (ie with rpm-4.9 and before). and even the spec will be cleaner and simpler. i may even add %{?_mingw32_debug_package} and the %{_mingw32_pre_spec} should have to put after the header part. i know most people do not care about old fedora and even rhel, but such small help can save a lots of time for a lots of people don't have to divert all and rewrite all spec file. i always prefer a little bit longer spec file if this result then it's work on all target. imho it's the biggest problem that in order to add mingw to rhel Andrew has to spend more then a few hours... not to mention Mikkel Kruse Johnsen, Marc-André Lureau etc... not to mention suse people etc... just i know w dozen of other people:-( just my 2c.
-
Farkas Levente -
Kalev Lember