libtool: OMF inconsistency

[dmik]

Switching between OMF and non-OMF (a.out) mode in our GCC tool chain is not very consistent. I.e. you can use -Zomf in the compiler but omit its usage in the linker and some tools (like nm) don't have OMF mode at all and will not work if -Zomf is used. External tools such as libtool know even less about these nuances and expose a bunch of various problems.

This is a meta-defect to gather all related libtool problems in a single place. Currently we have the following ones: #72, #74, #93.

[dmik]

The main problem, as said before, is that you can switch some parts to OMF and leave some at A.OUT. And this can be done not only with -Zomf but also with setting variables directly, i.e. you may only switch the librarian to OMF with AR=emxomfar. And this may cause problems like the one described #72.

Frankly, although inconsistency is generally bad situations may differ and theoretically there is a need that some project may require different modes for different tools. In this case it makes sense to detect individual tool settings and behave appropriately instead of forcing the whole tool chain to be either in EMF mode or not. This individual recognition is much more complex, though.

[dmik]

I've just released libtool 2.4.6-2 RPM with #72, #74 and #93 fixed (as well as #69). We are at least somewhere with this question now. In all known situation libtool should work correctly. I will leave this defect open to keep track of possible similar problems, if any.

[Silvan Scherrer]

this still doesn't work as it should. When you add AR=emxomfar then it uses .lib, which is ok. When a project now creates a statically library the corresponding .la file still is ok. When now a exe or dll links to that .la file the library name gets not added. And so the link fails. With .a as library name the .a is first unpacked and the exe or dll is linked against all .o. Eventually this sounds a bit complicated, but libjpeg-turbo shows exactly this behavior if AR=emxomfar is used.