wlink failure with lib file containing win32 COFF objects

[sezero]

Build the following test source with wcc386 -zq -bt=nt -5s -fo=1.obj 1.c :

extern int FLAC__stream_decoder_seek_absolute(void*);
int main(void) {
  return FLAC__stream_decoder_seek_absolute((void*)0);
}

And link it with FLAC.lib :

wcc386 -zq -bt=nt -5s -fo=1.obj 1.c
wlink N a.exe SYS NT_WIN OPTION q LIBR { FLAC.lib } F { 1.obj }
Error! E2082: file FLAC.lib(stream_decoder.c), record 1: invalid record type 0x002f
Error! E2082: file FLAC.lib(stream_decoder.c), record 2: invalid record type 0x0001
Error! E2082: file FLAC.lib(stream_decoder.c), record 3: invalid record type 0x0073
Error! E2082: file FLAC.lib(stream_decoder.c), record 4: invalid record type 0x0000
Error! E2011: file FLAC.lib(stream_decoder.c): invalid object file attribute

This is the lib file in question: FLAC.lib.zip

This error doesn't happen with wlink from OW19.

It doesn't seem to matter if FLAC.lib is built using wlib from ow1.9
or ow2.0.

The lib contains object files built using nasm with its -f win32 flag.
If the asm sources of the library were built using -f obj instead, then
wlink from ow2.0 succeeds.

[jmalak]

It looks like issue with COFF format libraries.
I will check and fix.

[sezero]

The lib was created with -q -b -n -c -pa -s -t -zld -ii -io flags of
wlib. However, the failure doesn't go away even if I use bare minimum
flags of -q -b -n -c with wlib when creating the lib. Also note that
the lib contains obj (omf) format objects along with win32 coff format
ones. I hope those additional info helps with things.

[jmalak]

I think issue happens only in situation if wlink uses COFF archive library with COFF objects.
Maybe also with COFF objects. Open Watcom build use only OMF libraries that no issue.
I will try to add some test for another formats (ELF and COFF) which is not currently used by Open Watcom build system.

[sezero]

P.S.: For the time being, I changed my projects to build nasm asm code in obj output format.

[FyiurAmron]

@jmalak I stumbled upon this same problem, but I have some additional info here, I think the problem goes a bit deeper than what's described. Please say whether this (related) problem should be handled here, or whether another separate issue should be created.

WLIB creates AR libs for non-OMF objs even if explicitly requested not to, and issues no warning/error in such cases. I believe that shouldn't happen. If providing a purely OMF OBJ(s), WLIB respects the command-line flags, and generates either OMF or AR lib (with the default behaviour being equal to -fo). However, if providing "affected" OBJ, WLIB ignores the flags and always generates AR without saying anything even with -fo flag - see the attached zip with examples.

allegro.hw.zip

We have two coupled problems - first, WLIB silently creates AR files even though asked not to (even though having so as a default is reasonable, it's no longer reasonable with explicit flag for OMF lib), and then WLINK fails to link them without saying why explicitly (as in the error message from @sezero ).

Note that manual linking of both the OBJs provided succeeded - only the library-based approach fails.

[jmalak]

Thanks for your info.
This rather confirm that issue could be caused by bug in ORL project which is shared by WLIB and WLINK.