Fix BLDLEVEL for gcc1.dll #11

New Issue

claunia · 2026-01-29T22:22:56Z

claunia commented

2026-01-29 22:22:56 +00:00

Originally created by @dmik on GitHub (Jan 14, 2020).

The new release of RPMs for GCC version 9 from #6 contains DLLs with a nice BLDLEVEL string thanks to this libtool fix: 60849038f6. 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: ee72211e30/libgcc/config/i386/t-emx (L16)

Note that Yuri unconditionally refers to RPM_PACKAGE_RELEASE there which is only defined under rpmbuild. 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 RPM_PACKAGE_* 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).

Originally created by @dmik on GitHub (Jan 14, 2020). 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 under `rpmbuild`. 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 RPM_PACKAGE_* 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).

claunia commented

2026-01-29 22:22:57 +00:00

@dmik commented on GitHub (Jan 15, 2020):

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

@dmik commented on GitHub (Jan 15, 2020): 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.

claunia referenced this issue

2026-01-29 22:23:05 +00:00

Suport ELF as object format #14

claunia referenced this issue

2026-01-29 22:24:12 +00:00

Investigate why alignas(8) doesn't always work #36

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: bitwiseworks/gcc-os2#11