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.

[jmalak]

I did analysis of your library and it is mixture of objects with different format.
On the begining is a few COFF objects and rest is OMF objects all encoded in archive format.
It is little bit strange construct.
OW 2.0 wlink has little bit different processing that expected that library has objects with same type.
I will check and fix to do correct detection on object level even if it is overall archive format.

The main issue is that you combine two different formats in the library therefore wlib desided to create archive format and include there all your object types. wlib cannot create OMF library if you include COFF or ELF objects but can create archive format and mix object type there. Probably we should add some diagnostics which will warn about this situation that you ask OMF library but it is not possible and wlib create different library format with possible objects combination.

Anyway wlink has bug for such libraries processing and need to fix because such library format is legal.

[jmalak]

Please could you check creation of your library (with mixed object types) by OW 1.9 wlib, what happen?
Probably behaviour should be same, no warning but create mixed archive library.

[sezero]

Please could you check creation of your library (with mixed object types) by OW 1.9 wlib, what happen? Probably behaviour should be same, no warning but create mixed archive library.

As I told before, wlink from ow2.0 fails, wlink from ow19 succeeds.

In any case, here are lib files created with oq19 and ow20:

lib-ow19.zip

lib-ow20.zip

OW20 version used was from 28 Aug 2024. If you really need me to use the latest,then tell me.

As I told before, for both ow19 and ow20, the wlib command line switches used
for lib creation are the same: -q -b -n -c -pa -s -t -zld -ii -io

Do you need anything else?