Patches from OS/2 RPMs

[dmik]

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

[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.

[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.

[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.

[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).

[dmik]

Updated 005 patch.

[dmik]

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

[dmik]

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

[Yuri Dario]

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.

[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_*).

[diver]

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

[bird]

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...)

[dmik]

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