Opened 8 years ago

Closed 5 years ago

Last modified 5 years ago

#109 closed enhancement (fixed)

Patches from OS/2 RPMs

Reported by: dmik Owned by: bird
Priority: major Milestone:
Component: kBuild Version: 0.1.5
Keywords: Cc: Yuri Dario, abwillis, psmedley


To gather patches we apply in the RPM release of kBuild on OS/2.

Attachments (8)

001-os2_deault_inst_dll_to_bin.patch (473 bytes) - added by dmik 8 years ago.
002-gcc3omf_make_ld_ar_quiet.patch (1.6 KB) - added by dmik 8 years ago.
003-gcc3omf_support_dll_as_library_source.patch (1.9 KB) - added by dmik 8 years ago.
004-gcc3omf_add_rc_support.patch (4.8 KB) - added by dmik 8 years ago.
005-gcc3omf_gen_implib_for_dll.patch (2.7 KB) - added by dmik 8 years ago.
kbuild-005-gcc3omf_gen_implib_for_dll.patch (2.8 KB) - added by dmik 7 years ago.
Updated 005 patch.
kbuild-006-fix-os2-build.patch (414 bytes) - added by dmik 7 years ago.
kbuild-007-gcc3omf_add_rc_support-NEW.patch (8.1 KB) - added by dmik 7 years ago.

Download all attachments as: .zip

Change History (22)

Changed 8 years ago by dmik

Changed 8 years ago by dmik

comment:1 Changed 8 years ago by dmik

That's it currently. The names are pretty much self descriptive. Please inform if/when you apply any of these patches so that we can remove them from the RPM.

Changed 8 years ago by dmik

comment:2 Changed 8 years ago by diver

the rc support patch isn't 100% right, as it assumes always IBM rc.exe in the linking stage. this gives problems, if one used _RCTOOL=OPENWATCOM to build the .res files. imho this patch needs to use the rc from RCTOOL is present.

comment:3 Changed 8 years ago by dmik

This is a bit more complex. The problem is that RC and WRC produce incompatible output (and have incompatible input). Technically it's just an accident that the compiler and linker of the GCC3OMF tool recognize EMXOMF_RC and EMXOMF_RC_TYPE variables and can compose the correct resource compiler call based on that.

By changing _RCTOOL (or any other source level tool), you only change what tool will compile a particular kind of sources (based on the extension) to an intermediate object file. It assumes that, if not the input, but at least the output of this new tool (i.e. the intermediate file it creates) is compatible with the main tool you are partly overriding, since changing the source level tool doesn't affect the link stage (where the output of this tool is linked into the final executable) which is solely defined by the main tool itself.

You could solve it nicely if kBuild provided an opportunity to override the link step when you override some particular tool, but AFAIK it does not have anything like that ATM (Knut will correct me if I'm wrong).

So, given what we have, I think the best will be to change the GCC3OMF tool so that it will rely on EMXOMF_RC both when selecting its RCTOOL and at the link stage, and don't care about other compilers ATM (e.g. OPENWATCOM/VAC) assuming that they always use their native tool. I will change the patch.

Changed 8 years ago by dmik

comment:4 Changed 8 years ago by dmik

Added one more patch that causes GCC/GXX tools to automatically generate import libraries for DLL targets and place them to $(PATH_STAGE_LIB) (as on other platforms like Windows). This feature may be disabled by putting KMK_NOIMPLIB to _LDFLAGS (needed since some existing projects, like Odin, don't expect automatic import library creation).

Changed 7 years ago by dmik

Updated 005 patch.

comment:5 Changed 7 years ago by dmik

In the updated patch, I fixed the kmk warning about overriding the make target.

Changed 7 years ago by dmik

comment:6 Changed 7 years ago by dmik

Patch 006 fixes the OS/2 build break since 2662.

comment:7 Changed 7 years ago by Yuri Dario

Cc: Yuri Dario added

It seems to me that 004-gcc3omf_add_rc_support.patch​ is wrong, because it manually adds .res file in line 274/275 (and similars), but the .rsp file is already including the compiled resource, so then .res file ends up being added twice.

comment:8 Changed 7 years ago by dmik

Well yes there was such a bug in patch 004 but it's harmless and not the reason of your failure with WRC. I redesigned the patch and attaching it as 007 here. The new RPM is already in the repo.

Note that you don't need to (and must not) do _RCTOOL = OPENWATCOM any more. The new code will properly derive the RC tool from the GCC environment vars (EMXOMFLD_RC_*).

comment:9 Changed 7 years ago by abwillis

Cc: abwillis added

comment:10 Changed 7 years ago by psmedley

Cc: psmedley added

comment:11 Changed 7 years ago by diver

could you look at those fixes and eventually add some for the next release?

comment:12 Changed 5 years ago by bird

Resolution: fixed
Status: newclosed

001-os2_deault_inst_dll_to_bin.patch is of course rejected. It will break other projects and you can override INST_DLL = $(INST_BIN) in your probject's Config.kmk.

I've made all tools quiet now, so 002-gcc3omf_make_ld_ar_quiet.patch​ is in. Thanks for the reminder.

Handing %.dll source files to emximp alongside %.imp and %.def files is now done in all GCC tools, not just the OMF ones, so 003-gcc3omf_support_dll_as_library_source.patch​ is in.

The whole RC business is kind of solvable by setting RCTOOL=OPENWATCOM or RCTOOL=VAC308 in your project and selecting what you want. I don't think GCC3OMF/GXX3OMF should start second guessing your preferred RC too much. I'm also reluctant trying to replicate the long environment setup that OPENWATCOM.kmk does for invoking WRC in two more only half related places. So, I decided to add simple support for compiling .rc files into .res files similar to VAC308, but let emxomfld deal with the .res files the way it thinks best. The only expensive thing there, is that I need the actual GCC include path, so there are a couple of $(shell ) invocations during makefile load if you have targets with .rc files. (Btw. is the latest an greatest wrc.exe still unable to read res files produced by rc.exe? I though Michal said something had been changed in that area...)

comment:13 Changed 5 years ago by dmik

Type: enhancementdefect

Thanks for applying most of the patches. The current version of wrc I have (and which our RPM has, 2.0beta1 LA) seems to be able to successfully handle res files generated by rc. At least I was able to attach the Icon resource to the executable (though WRC, as opposed to RC 5, doesn't set the .ICON EA on the file in such case).

Regarding patch 001, could you please give a couple of examples of projects that it will break? Perhaps, you mean the package generation script that won't find a dll in the previous location...

Last edited 5 years ago by dmik (previous) (diff)

comment:14 Changed 5 years ago by dmik

Type: defectenhancement
Note: See TracTickets for help on using tickets.