WLink "memory could not be read" exception

[Pokeman2003]

I'm using the December 2nd 32-bit Windows build.
I have a basic linker script that looks like this. By all accounts, I think this should link. It doesn't look too dissimilar to the examples provided, other than the absurd list of libraries I included to stop a different error.

system nt
option map
name output
file W:\Project\CompileFolder\Backend\File\Ingress.obj
file W:\Project\CompileFolder\Backend\Localization\LocalEN.obj
file W:\Project\CompileFolder\Backend\Localization\LocalFallback.obj
file W:\Project\CompileFolder\Windows\Initialize.obj
library W:\WATCOM\CC++\lib386\cplx3r.lib
library W:\WATCOM\CC++\lib386\cplx3s.lib
# Skipped the majority of these, since it's literally just a dump of every *.lib file from lib386 and lib386\nt.
# I wish I knew what libraries were actually necessary.
library W:\WATCOM\CC++\lib386\nt\wsock32.lib
library W:\WATCOM\CC++\lib386\nt\wtsapi32.lib

Instead of linking, my linker has a very, very angry output instead. On top of the non-sense warning, it also spits out an exception.

Warning! W1107: file W:\Project\CompileFolder\link: line(1): undefined system name: nt
Warning! W1014: stack segment not found
The instruction at 0x69c2200e referenced memory at 0x00000008.
The memory could not be read.
Exception fielded by 0x00403000
EAX=0x00000000 EBX=0x0019fcd1 ECX=0x00000000 EDX=0x0019fcc0
ESI=0x0019fd30 EDI=0x0019fcd0 EBP=0x0019fd18 ESP=0x0019fc80
EIP=0x69c2200e EFL=0x00010246 CS =0x00000023 SS =0x0000002b
DS =0x0000002b ES =0x0000002b FS =0x00000053 GS =0x0000002b
Stack dump (SS:ESP)
0x00000000 0x0000ffff 0x00000000 0x69c2d193 0x00000000 0x004757b9
0x00040000 0x0019fd60 0x0019fcc0 0x69c21007 0x0019fcec 0x0019fd00
0x0019fd18 0x0019fcec 0x0019fd18 0x69c22639 0x00000008 0x00000004
0x000000b8 0x00b80007 0x0019fd18 0x0019fcec 0x00472510 0x00472510
0x00000000 0x00000006 0x69c22796 0x000015ff 0x69c50000 0x0019fd8c
0x00000002 0x0019fd60 0x00000008 0x0019fd60 0x0019fd28 0x69c5445c
0x00000008 0x69c229b2 0x0019fcee 0x00000000 0x000000b8 0x00000001
0x00000000 0x0000ffff 0x06040202 0x00000400 0x00000000 0x0000ffff
0x06040202 0x00000008 0x0019fd68 0x0019fe48 0x004020ca 0x0019fe20
0x0047e184 0x69c22af6 0x00590311 0x69c38502 0x69c544f0 0x69c54406
0x06040202 0x0047e184 0x0000006c 0x69c22a40 0x69c2bfe3 0x001f11b0
0x69c28cc0 0x004741d1 0x00000000 0x69c28c8e 0x69c33b80 0x69c28c62

Here is the linking environment, and here is my compilation environment if you so desire.

[Pokeman2003]

I think I know what happened, actually. Let me do a bit more testing.

What's the difference between the R and S libraries? I suspect mixing them is the problem. Preliminary testing of just including the R libraries seemed to "work" but it just asked me for a library I was already including.

[jmalak]

Thanks for your bug report.
The crash is not OK it will be fixed.

Anyway from the first message
Warning! W1107: file W:\Project\CompileFolder\link: line(1): undefined system name: nt
is clear that you have not properly configured Open Watcom and wlink has not defined any system due to missing definition file.
Please configure Open Watcom properly.

• WATCOM environment should be defined and point to the root of your OW installation
• PATH must contains OW binary subdirectory which contains OW binaries for your host Operating system
• INCLUDE must contains OW header subdirectory which contains OW header files for your target Operating system

[Pokeman2003]

I am desperately trying to avoid environment variables for portability reasons, and had been under the assumption that the environment variables were used strictly by the IDE itself. I've managed to pass the correct header files using a -i inclusion, so I've at least gotten that far. If you know, why are the others necessary?

[jmalak]

You complicate your live by your jiggery pokery.
Normally you setup WATCOM and PATH which define your host and by defining INCLUDE you define target.
It is trivial setup by tree environment variable, I don't understand what problem.
It is supported by any OS shell or make system.
As soon as you are trying to be clever you broke configuration and start your problems.
Simply use all tools as simple name and add appropriate host binaries subdirectory to the PATH as normal application configuration. PATH doesn't need any change after setup and all works OK.

If you want to use OW then run simple configuration batch file and next you can use it without jiggery pokery or if you have permanent configuration than modify your default environment.

[Pokeman2003]

Git forces me to use an absolute path, so I began using virtual drives to organize my projects because it makes switching between my laptop and desktop easier. I also prefer to keep the tools on the virtual drive, despite redundancy, in case I want to program on a machine that doesn't have these tools.

Something to note is that Windows and DOS are both operating systems that are primarily meant to handle portable installations. Yeah, there's plenty of programs that ignore this convention, but it's like how alt+enter is supposed to be the fully screen keybind by Windows' own convention, despite few programs actually using this keybind for that.

Anyways all of this to say is that I'm running one last test because I think someone may have conflated an environment variable and a regular variable in the manual back when it was first written. There is a huge operational difference between the two(you couldn't even set the former in Batch before Windows 7,) but the linker manual has at least a hint suggesting they may be taking from the regular variables instead. If my test fails, no harm no foul I'll just redo the installation.

[jmalak]

We are not depending on any OS specific because Open Watcom is by nature cross-compiler.
By example you install it on DOS and run only setup batch and you can compile to any target on DOS.
If you install it on Linux then you run batch script and you can compile to any target same way.
Nothing specific per host OS.
It is absolutely portable to any OS, only 3 environment variables need to setup.

[Pokeman2003]

That's not what portable means(in this instance.) When I say portable, I mean the definition that says the installation is self-contained and can have its directory changed at will without affecting operations of the program.

[jmalak]

You can copy OW tree anywhere and run batch file to setup 3 environment variables or add it to the system or user environment, it is not portable?

[Pokeman2003]

Last post before I go test.
Environment variables are GLOBAL variables that are available at all times, regardless of circumstances in a Batch script. As far as I'm aware, setenv has continued to be the only way to set them on Windows NT machines with batch. These are very different and can even be accessed outside of a batch call for the reason of "they are literally global to the machine/user." This is VERY MUCH not portable because it is a FIXED change, like adding a registry key.
There are REGULAR variables that are set with just a plain set command. They can be expanded by batch, and while this is the first time I've ever heard of a program being able to read them outside of the built-in shell executables, it wouldn't surprise me if there was a means to do so. This is what I'm going to go test.
Everything I just said is totally untrue. I don't know how the hell I managed it, but I somehow managed to mash Windows and Linux together in my head in what would've been the perfect shitpost on another day.

[jmalak]

Sorry you are wrong, environment setup can be various, temporary or user specific or system.
Open Watcom don't limit you anyway, you can use various method it depends on your requirements.
On my development system I have various OW installations and before any work I run simple appropriate setup script for 3 environment variables and nothing more after that I work with appropriate OW version without anything specific. It ensures that any make file is working properly on the host system and for target system and I don't need to modify it.

[Pokeman2003]

Yeah you're right, I'm wrong. I was wondering why setenv wasn't working. Oops.

[Pokeman2003]

Yeah okay, well that solves that bit and simplifies the script down immensely. An impressively overengineered solution, defeated by a simple setlocal to make sure I don't make a mess out of my path variable. Jesus Christ, what is wrong with me...

It's going to be really funny if it turns out that the linker crash is caused entirely because of my overengineering(it already had a similar issue because I used quotation marks.) We're about to find out.

[Pokeman2003]

Honestly I'm not even sure if you can replicate my crash without the complete misunderstanding of the very operating system you're using.
(Yes, adding the environment variables fixed the crash.)

This was very embarrassing and I apologize for wasting your time like this.

[jmalak]

No problem, now you understand how it should be and don't create your own problems.
You need not solve such issue anymore.
You need only create portable make files and if you will move to another system only change these environment variables and all should going OK.