OK, as you know, #1 only works with OW tools.
I think perhaps your understanding of how GCC works is incomplete. GCC itself will call the linker.
gcc -g test.c -o test.exe
will compile test to an aout object file and link with ld.exe, it won't produce a debuggable binary (it did way back)
gcc -g -Zomf test.c test.exe
Will convert the aout object file to omf and link with emxomfld.exe, which depending on environment settings will massage the command line for a native linker,
Environment variables:
EMXOMFLD_TYPE:
The type of linker we're using. Values: WLINK, VAC365, VAC308, LINK386.
WLINK wlink.exe from Open Watcom v1.5 or later.
VAC365 ilink.exe from IBM C and C++ Compilers for OS/2 v3.6 or later.
VAC308 ilink.exe from Visual Age for C++ v3.08.
LINK386 link386 form OS/2 install or DDK.
EMXOMFLD_LINKER:
Name of the linker to use and optionally extra parameters. Spaces in the
linker name or path is not supported. Quotes are not supported either.
The default values for these two variables are VAC365 and ilink.exe.
There's also environment variables for rc, run emxomfld without arguments to see all options.
So while it is possible to link directly with wlink, it is tricky and really you should use GCC to link.
Both of these work, (going from memory)
gcc -g test.c -o test.o
gcc -g -Zomf test.o -o test.exe
gcc -g -Zomf test.c -o test.o
gcc -g -Zomf test.o -o test.exe
With CFLAGS=-Zomf, things can get more complex, static libs use emxomfar instead of ar, ranlib will fail on a omf static lib, do SET AR=emxomfar, SET RANLIB=ECHO for that scenario.
Usually omf libs end in .lib and aout ones in .a