Open dmik opened 4 years ago
Just for the record, there is a temporary hack in gcc.spec which should get removed, once this ticket is fixed in the source tree: https://github.com/bitwiseworks/rpm-specs/commit/bb3932145f7793d65c5c7f5b75f4730f28acf07a.
The new release of RPMs for GCC version 9 from #6 contains DLLs with a nice BLDLEVEL string thanks to this libtool fix: https://github.com/bitwiseworks/libtool-os2/commit/60849038f64e593bd4a8deda5321488a0c90786c. However,
gcc1.dll
isn't built using Libtool and hence it didn't get a proper BLDLEVEL string but instead just a textual description. In order to do so, we need to fix its makefiles (to use the LT_BUILDLEVEL environment variable manually).The place where it is set now is this: https://github.com/bitwiseworks/gcc-os2/blob/ee72211e306d422d506b6016ded65ee00a2df96a/libgcc/config/i386/t-emx#L16
Note that Yuri unconditionally refers to
RPM_PACKAGE_RELEASE
there which is only defined underrpmbuild
. This produces weird description in non-rpmbiuld
development builds and should have been done conditionally. At least this is how we will make LT_BUILDLEVEL used here.Note that the presence of RPM_PACKAGE_VENDOR, RPM_PACKAGE_VERSION and RPM_PACKAGE_RELEASE environment variables with the respective values under
rpmbuild
could let us avoid introducing LT_BUILDLEVEL (see https://github.com/bitwiseworks/libtool-os2/issues/1) at all. But still, this would require to patch Makefile.am for each and every DLL we build in order to incorporate conditional RPMPACKAGE* usage on OS/2 there which is much more work than just define LT_BUILDLEVEL once in a .spec file (and not touch Makefile.am at all).