How to set up 16-bit DOS Open Watcom target linking?

[ta0]

My Open Watcom (2.0 fork) installation works and can produce working .EXE's. Also, the pre-installed W32 target for Open Watcom works like expected inside C::B. So I copied it (with Settings -> Compiler -> Global compiler settings -> The "Selected compiler" box -> Copy) and then made the necessary path and toolchain changes.

The compile phase through WCL.EXE passes. WLINK.EXE, however, fails:

wlink.exe option quiet  LIBP  c:\watcom\lib386 obj\Debug\main.obj name bin\Debug\hello.exe  
Error! E3033: directive error near 'obj\Debug\main.obj'

If I manually run this on the command line it seems that a "file" directive is missing in front of the object name, because this works:

wlink.exe option quiet  LIBP  c:\watcom\lib386 file obj\Debug\main.obj name bin\Debug\hello.exe

I cannot find where this file directive is specified in the built-in W32 Open Watcom target. What is going on?

[ta0]

Update:

In OW W32, there this line in Settings -> Compiler -> Global compiler settings -> Other settings -> Advanced options -> Commands -> Command: "Link object files to console executable":

$linker option quiet $link_options $libdirs $link_objects name $exe_output $libs $link_resobjects

If, for my OW DOS-16 target, I change that line to:

$linker option quiet $link_options $libdirs file $link_objects name $exe_output $libs $link_resobjects

then it will build successfully, but for single object projects only, of course. So my question is how does the file "prefix" end up before every $link_objects object?

And if there's no immediate fix for this, how can I override the linker and use my own static linking line from within C::B ?

[stahta01]

Did you try setting the object directory to "." as a work around?
Note: Do not use the quotes just use the period.

If that does not work I would try using empty or space in the object directory setting.

Tim S.

[ta0]

Thanks for replying, but I think you misunderstand.

The problem is that my copied configuration does not output the directive file before the $link_objects when making the arguments string for wlink.

What is really surprising is that the target config I copied (Open Watcom W32) DOES output file, even though I cannot find it specified anywhere, even in the Advanced Options.

[stahta01]

Thanks for replying, but I think you misunderstand.

The problem is that my copied configuration does not output the directive file before the $link_objects when making the arguments string for wlink.

What is really surprising is that the target config I copied (Open Watcom W32) DOES output file, even though I cannot find it specified anywhere, even in the Advanced Options.

Did you check or did you NOT check the advanced compiler options?

Because that is where the problem needs to be fixed.

Tim S.

[Alpha]

Code: src/plugins/compilergcc/directcommands.cpp

wxArrayString DirectCommands::GetTargetLinkCommands(ProjectBuildTarget* target, bool force) const
{
[...]
    bool IsOpenWatcom = target->GetCompilerID().IsSameAs(_T("ow"));
[...]
    if (IsOpenWatcom && target->GetTargetType() != ttStaticLib)
        linkfiles << _T("file ");
[...]

This does not look good...

[stahta01]

I agree that does NOT look good.

Tim S.

PS: Now I think I might understand the first post, better.

Code: src/plugins/compilergcc/directcommands.cpp

wxArrayString DirectCommands::GetTargetLinkCommands(ProjectBuildTarget* target, bool force) const
{
[...]
    bool IsOpenWatcom = target->GetCompilerID().IsSameAs(_T("ow"));
[...]
    if (IsOpenWatcom && target->GetTargetType() != ttStaticLib)
        linkfiles << _T("file ");
[...]

This does not look good...

[ta0]

   if (IsOpenWatcom && target->GetTargetType() != ttStaticLib)
        linkfiles << _T("file ");

Lol, that's a hack if I ever saw one

Anyway, for anybody having the same problem and arriving here by way of google, here's the very simple and straight forward work-around for people wanting to use OW to build for 16-bit DOS:

Copy the OpenWatcom (W32) Compiler target config to a new one, let's call it OpenWatcom DOS16.

In Settings>Compiler>Global compiler settings> [select OpenWatcom DOS16 as Selected compiler] > Other Settings>Advanced options...>Commands>Command:Link object files to console executable:

$linker option quiet form DOS $link_options $libdirs file $link_objects name $exe_output $libs $link_resobjects

and in Others>Object separator, make sure it is a simple comma (","). (So, we're adding form DOS to make sure wlink.exe builds a DOS .EXE, and file in front of $link_objects because that's how wlink.exe wants it)

Repeat similarily for the other types of Command: commands (Link object files to dynamic library, static... etc).

Then change the Settings>Compiler>Global compiler settings>Toolchain executables to:

C compiler: wcl.exe
C++ compiler: wcl.exe

You will also need the following in Settings>Compiler>Global compiler settings>Search directories
Compiler:
c:\watcom\h
Linker:
c:\watcom\lib386
c:\watcom\lib386\dos
c:\watcom\lib286
c:\watcom\lib286\dos
Resource compiler:
c:\watcom\h

In Settings>Compiler>Global compiler settings>Build options
Number of parallel builds: 1
(otherwise the linker will fail because it can only run one instance at a time)

Further, I'd use 8.3 compliant paths and file names for less frustration potential.

This is in the general case, you might of course need other files for the linker and include directories depending on your project.

So, the only problem with copying the OpenWatcom (W32) Compiler target is that the magic behavior of the file directive is not carried over, for obvious reasons. In fact, this is not really a work around at all, because the magic behavior for (W32) is completely unnecessary; it could be handled by the regular target options.

I'm running Code::Blocks 13.12 in Windows XP, and "Open Watcom C x86 16-bit Optimizing Compiler
Version 2.0 beta Apr 27 2014 22:29:25", that is the v2 fork by Jiri Malak. I have not actually tried anything else than building a very basic multi source file DOS16 console app, and I suspect that dynamic libraries etc will actually need further tweaks in Advanced options... to build. Of course the above only applies exactly like this if you have installed the OpenWatcom compiler into c:\watcom, and selected to install the DOS compiler components when running the OpenWatcom installation program.

[stahta01]

Possible patch that needs tested by a person using Open Watcom.

Code

Index: src/plugins/compilergcc/directcommands.cpp
===================================================================
--- src/plugins/compilergcc/directcommands.cpp	(revision 9936)
+++ src/plugins/compilergcc/directcommands.cpp	(working copy)
@@ -677,8 +677,6 @@
             ret.Add(wxString(COMPILER_SIMPLE_LOG) + _("Linking stage skipped (build target has no object files to link)"));
         return ret;
     }
-    if (IsOpenWatcom && target->GetTargetType() != ttStaticLib)
-        linkfiles << _T("file ");
     bool subseq(false);
     for (unsigned int i = 0; i < files.GetCount(); ++i)
     {
Index: src/plugins/compilergcc/resources/compilers/options_ow.xml
===================================================================
--- src/plugins/compilergcc/resources/compilers/options_ow.xml	(revision 9936)
+++ src/plugins/compilergcc/resources/compilers/options_ow.xml	(working copy)
@@ -436,15 +436,15 @@
     <Command name="CompileResource"
              value="$rescomp -q -r -fo=$resource_output $res_includes $file"/>
     <Command name="LinkExe"
-             value="$linker option quiet $link_options $libdirs $link_objects name $exe_output $libs $link_resobjects"/>
+             value="$linker option quiet $link_options $libdirs file $link_objects name $exe_output $libs $link_resobjects"/>
     <Command name="LinkConsoleExe"
-             value="$linker option quiet $link_options $libdirs $link_objects name $exe_output $libs $link_resobjects"/>
+             value="$linker option quiet $link_options $libdirs file $link_objects name $exe_output $libs $link_resobjects"/>
     <Command name="LinkDynamic"
-             value="$linker option quiet $link_options $libdirs name $exe_output $libs $link_objects"/>
+             value="$linker option quiet $link_options $libdirs name $exe_output $libs file $link_objects"/>
     <Command name="LinkStatic"
              value="$lib_linker -q $static_output $link_objects"/>
     <Command name="LinkNative"
-             value="$linker option quiet $link_options $libdirs $link_objects name $exe_output $libs $link_resobjects"/>
+             value="$linker option quiet $link_options $libdirs file $link_objects name $exe_output $libs $link_resobjects"/>
     <Common name="cmds"/>
 
     <RegEx name="Note"

I did only very minor testing using OpenWatcom 32 bit.

Tim S.

[mrmoelgaard]

Hello,

Excuse for resurrecting this topic. I'm using Code::Blocks as an IDE for Open Watcom in a project that targets DOS 16. My project is structured in a number of libraries linked into a console application.
I'm struggling with setting up the compiler options to achieve this an came across this post in my search for a solution.
I had already adjusted my advanced options to the settings described here. I compared the build log in the Open Watcom IDE with Code::Blocks to get it working.

But there's an issue when working with libs since wlink and wlib use different syntax for the object list.
wlink.exe requires a list of obj files separated by comma
wlib.exe requires a list of obj files separated by space

In the Other options there's only one "Object separator" so I'm a little challenged by the tool. I'm using Code::Blocks version 13.12 with Open Watcom 1.9 (latest) on a Windows 7 PC.
Any advice would be highly appreciated since I've become really fond of using Code::Blocks instead of the Open Watcom IDE.

Thanks in advance.

Best regards
Emil Moelgaard

[stahta01]

Hello,

Excuse for resurrecting this topic. I'm using Code::Blocks as an IDE for Open Watcom in a project that targets DOS 16. My project is structured in a number of libraries linked into a console application.
I'm struggling with setting up the compiler options to achieve this an came across this post in my search for a solution.
I had already adjusted my advanced options to the settings described here. I compared the build log in the Open Watcom IDE with Code::Blocks to get it working.

But there's an issue when working with libs since wlink and wlib use different syntax for the object list.
wlink.exe requires a list of obj files separated by comma
wlib.exe requires a list of obj files separated by space

In the Other options there's only one "Object separator" so I'm a little challenged by the tool. I'm using Code::Blocks version 13.12 with Open Watcom 1.9 (latest) on a Windows 7 PC.
Any advice would be highly appreciated since I've become really fond of using Code::Blocks instead of the Open Watcom IDE.

Thanks in advance.

Best regards
Emil Moelgaard

I am willing to try to help you; but, other than this thread I have NOT used Open Watcom.
You will need to post the correct command for Open Watcom to compile to object code.
And, the correct command need to link the object code to an 16 bit exe.

Links to download the Open Watcom 16 bit compiler/linker you are using would help me to test the changes I do.

Tim S.

[mrmoelgaard]

Hi, thanks for your assistance.

I've tried to create a small example that illustrates my challenge:

A library called MyLib includes two source files (types and calc). MyLib is then used by MyProg.exe through a handler. It is essential that both the library and the application consists of more than one source file. Otherwise there are no obj files to separate.

Code

wcl.exe -q -c -d2 -wx -ml -bt=dos -bcl=dos -iC:\WATCOM\h -fo=obj\Debug\types.obj types.c
wcl.exe -q -c -d2 -wx -ml -bt=dos -bcl=dos -iC:\WATCOM\h -fo=obj\Debug\calc.obj calc.c
wlib.exe -q MyLib.lib obj\Debug\types.obj obj\Debug\calc.obj

wcl.exe -q -c -ml -bt=dos -bcl=dos -iC:\WATCOM\h -fo=obj\Debug\main.obj main.c
wcl.exe -q -c -ml -bt=dos -bcl=dos -iC:\WATCOM\h -fo=obj\Debug\calcHandler.obj calcHandler.c
wlink.exe name MyProg.exe d all sys dos op m op maxe=25 op q LIBP C:\WATCOM\lib386;C:\WATCOM\lib386\dos FIL main.obj,calcHandler.obj library ..\MyLib\bin\Debug\MyLib.lib,lib\OtherLib.lib

The list of obj files sent to wlib.exe is separated by spaces. But for wlink it needs to be separated by commas.

Of course I have the option to create another copy of the compiler profile and have one setup for compiling library projects and another for exe projects.

Best regards
Emil

[stahta01]

I will try to take a look at the changes needed in the next few days.

Tim S.

Hi, thanks for your assistance.

I've tried to create a small example that illustrates my challenge:

A library called MyLib includes two source files (types and calc). MyLib is then used by MyProg.exe through a handler. It is essential that both the library and the application consists of more than one source file. Otherwise there are no obj files to separate.

Code

wcl.exe -q -c -d2 -wx -ml -bt=dos -bcl=dos -iC:\WATCOM\h -fo=obj\Debug\types.obj types.c
wcl.exe -q -c -d2 -wx -ml -bt=dos -bcl=dos -iC:\WATCOM\h -fo=obj\Debug\calc.obj calc.c
wlib.exe -q MyLib.lib obj\Debug\types.obj obj\Debug\calc.obj

wcl.exe -q -c -ml -bt=dos -bcl=dos -iC:\WATCOM\h -fo=obj\Debug\main.obj main.c
wcl.exe -q -c -ml -bt=dos -bcl=dos -iC:\WATCOM\h -fo=obj\Debug\calcHandler.obj calcHandler.c
wlink.exe name MyProg.exe d all sys dos op m op maxe=25 op q LIBP C:\WATCOM\lib386;C:\WATCOM\lib386\dos FIL main.obj,calcHandler.obj library ..\MyLib\bin\Debug\MyLib.lib,lib\OtherLib.lib

The list of obj files sent to wlib.exe is separated by spaces. But for wlink it needs to be separated by commas.

Of course I have the option to create another copy of the compiler profile and have one setup for compiling library projects and another for exe projects.

Best regards
Emil

[stahta01]

@mrmoelgaard: The problem has code changes in SVN that should have fixed the issue in the past.

What version of Code::Blocks are you using? SVN/Release info

Edit: I have NOT yet figured out if the past changes work or when they were done.

Edit2: Found a real problem; the project settings are being ignored for some things for the Watcom compiler.
Library paths, Library names, and likely some other things are being ignored.

Tim S.

[mrmoelgaard]

Hi,

I'm using the 13.12 binary release with MinGW bundle.

For now I'm using the workaround with two compiler setups, one for lib and one for exe. Not ideal but it gets the work done.
Let me know if there's another version I can test. Would that be latest nightly?

Best regards
Emil