Viktor:

Thanks for your test.

To me it rather seems like a GCC bug in -Zomf mode:
It creates objects with .o extension, while it "should"
use .obj. Or, it's possible that GCC decided to use .o
extension even for OMF objects, and it's only us trying
to force .obj.

So, we can either fall back to .o for gccomf mode also,
or we can start to hack GCC to force .obj extension, but
this has some drawbacks: f.e. in hbmk2 gcc will have to
be invoked for each .c source file separately, which is
much slower than calling it for all .c source files at once.
Plus it also widens the gap between gcc and gccomf mode.

I'd vote for first option, but for this we should know
for sure what is the official extension for objects in
GCC OMF mode.

In os2gcc the "gap" between a.out and OMF types are wide and clear, and
so must be
Is just a matter to know the whole picture and apply differences properly
Is not a bug in -Zomf mode

As other gcc versions, in os2gcc "native" extensions are:
- .o for objects
- .a for libraries
in both a.out and OMF types
  ... unless we change extensions

In os2gcc OMF type are usual to use, as I presented examples of other
OS/2 projects:
- .obj for objects
- .lib for libraries

OWatcom use .obj and .lib for OS/2-OMF too

The problem I see here is a lack of sync in hbmk2.prg between phases:
- .c compiling. Is using default .o because are not using our own set
cObjExt := ".obj"
- linking. Is using our own set cObjExt := ".obj"

but as you briefly expose, is a matter of technical facts in hbmk2.prg
which are not using "-o " in "hbmk2: C compiler command:"

Solution is clear: sync use of object extension in both phases

If you set in OMF:
  cObjExt := ".o"
then it will be equal to "native" object extension .o which is not
specified in .c compiling phase

If you set in OMF:
  cObjExt := ".obj"
then you must to use cObjExt in .c compiling phase too

As I understand, cObjExt in hbmk2.prg and OBJ_EXT in "make" are to set
our own extensions, and they must be used in any phase

And yes, you can use .o as object extension in OMF too, but try to follow most of OS/2 projects style using .obj and .lib in OMF

David Macias


_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour

Reply via email to