hi, digging into this -mms-bitfields problem (and openssl package) i come to the conclusion it'd be better if we can solve the whole cflags issue in some more general way. ie. currently rpm use RPM_OPT_FLAGS which use optflags which defined in /usr/lib/rpm/rpmrc and /usr/lib/rpm/**/macros. it'd be better if we somehow can define that the current build's platform is win32 and rpm set all flags according to it. this's exactly what i do in %_mingw32_env, but if we can use some kind of rpm internal mechanism, then probably we can build much more easily native fedora packages. eg in case of openssl the native package hack Configure in openssl-0.9.8g-redhat.patch to use RPM_OPT_FLAGS. so we can use the same patch the same mechanism to for mingw too and in this case it'll work for all packages (where we'll forget about -mms-bitfields and may be other flags). in case of openssl we still need some ugly hack but in case of other packages this may help a lot. is there any rpm gurus here? yours.
On Mon, Dec 29, 2008 at 06:01:21PM +0100, Farkas Levente wrote:
hi, digging into this -mms-bitfields problem (and openssl package) i come to the conclusion it'd be better if we can solve the whole cflags issue in some more general way. ie. currently rpm use RPM_OPT_FLAGS which use optflags which defined in /usr/lib/rpm/rpmrc and /usr/lib/rpm/**/macros. it'd be better if we somehow can define that the current build's platform is win32 and rpm set all flags according to it. this's exactly what i do in %_mingw32_env, but if we can use some kind of rpm internal mechanism, then probably we can build much more easily native fedora packages. eg in case of openssl the native package hack Configure in openssl-0.9.8g-redhat.patch to use RPM_OPT_FLAGS. so we can use the same patch the same mechanism to for mingw too and in this case it'll work for all packages (where we'll forget about -mms-bitfields and may be other flags). in case of openssl we still need some ugly hack but in case of other packages this may help a lot. is there any rpm gurus here?
Whatever the answer is, if it involves changing base rpm packages, it has to be discussed on fedora-devel-list (or even the upstream rpm.org list). It's not something we can even speculate about here ...
Rich.