Viktor:
>> And is using .obj in OMF type, as usual:
>> E:/usr/lib/dll0.obj
>>
>> OBJ_EXT are forced to .o
>Forced. I have to tell you that I can't remember
>the whole lengthy discussion before implementing
>this the way it is now, but since it takes near
>zero effort to switch to .obj in .mk files, .o
>is used consistently in build/hbmk2, and since
>you didn't report any problems with any of the
>discussed gcc versions, I must assume we settled
>for .o for good reason. Also note I don't personally
>mind what extension does gcc actually requires.
>Now it's "forced".
>If current state is suddenly wrong for whatever
>reasons, tell clearly what happened in between,
>and what you suggest now for a solution.
The reason was hbmk2 feature:
"you lose the option to build multiple .c input files"
You can check "OS/2: hbmk2" messages, for example
Re: OS/2: hbmk2
5/11/09 04:59 AM
is included below
.obj is for OMF type a "convention" in OS/2 world, as .lib does too
gcc -v show this convention in use of:
E:/usr/lib/dll0.obj in OMF type
and
E:/usr/lib/dll0.o in a.out type
Until today Harbour and hbmk2 work fine using .o, but we must remember
.obj in OMF when using other object files which not belong to Harbour
David Macias
Viktor:
>So in Harbour we try to force some alien extension instead
>of .o which is the default extension in both OMF and a.out
>modes.
>> Solution is clear: sync use of object extension in both phases
>I know. However I don't like this approach. Speaking
>of both Harbour build and hbmk2, we use the default
>extensions for all supported compilers.
>For some reason this was violated by using .obj for
>gccomf. Not being an OS/2 user this wasn't apparent
>to me, I used what I saw.
>Using non-default extensions have some drawbacks,
>since you need tell each tool your extension of choice.
>In case of gcc, this is -o, however in this mode,
>you lose the option to build multiple .c input files
>at one pass. Which in turn makes performance much
>worse in certain cases. Plus it introduces an exception
>in both hbmk2 and Harbour build. Latter isn't affected
>too much as it doesn't use optimized calls to compiler
>using multiple inputs, but in hbmk2 this would need
>some extra logic to handle this exception case.
>For a peace of mind and "standardness", I vote to follow
>compiler defaults, whatever these are. No need to fight
>what GCC developers have decided on. With the case of .obj,
>we're trying to mimic other OS/2 compilers doesn't seem like
>a good idea.
>I could sure spend a few hours on it, but 1) I don't
>have time for it now 2) This would create an
>unprecedented exception for gccomf, which I don't think
>is a good idea on the long run (it has to be maintained).
>+1) Since this is not the default in GCC, I assume they
>had a good reason to make this decision, and any
>3rd party tool is better not reinvent the wheel
>since it may just cause problems down the road.
>Once GCC OS/2 porters decide to switch to other
>extension, we can follow suit.
>The idea is to use as few forced stuff and special
>tricks as possible. On some occasions gcc -o _is_ used
>even now, but only if inevitable (in -inc mode f.e.).
>If .o/.a is unusual for OS/2-OMF, the best place to
>complain is GCC OS/2 developers.
Due origin from a.out type only, for gcc .obj, .lib, -Zomf,
EMXOMFLD_TYPE, EXOMFLD_LINKER are aliens but they are well known and
accepted in OS/2 environment
Remember, os2gcc work with their own aliens and they should be well
managed/applied
Other aliens for gcc in OS/2 are:
-Zcrtdll, -Zdll, -Zexe, -Zhigh-mem, -Zlinker, -Zmap, -Zno-autoconv,
-Zautoconv, -Zargs-wild, -Zargs-resp, -Zdll-search, -Zsym, -Zhigh-low
-Zno-fork, -Zno-unix, -Zbin-files, -Zbsd-signals, -Zmt, -Zmtd, -Zmts
-Zno-rte, -Zsmall-conv, -Zstack, -Zso, -Zsys, -Zsysv-signals
EMXOMFLD_RC_TYPE, EMXOMFLD_RC
emxomfar.exe, emxomfld.exe, emxomf* family
I do not understand next two:
* _wildcard (int *argc, char ***argv): Same as in EMX, i.e. it
expands it's arguments like a unix shell would do (but OS/2 cmd.exe
doesn't), so you typically want to use this when porting a unix command
line application. Instead of adding this to a program, compilation with
-Zargs-wild can be used.
* _response (int *argc, char ***argv): Same as in EMX. Expand
response files (@FILENAME). The FILENAME contains a list of arguments,
one per line. Arguments enclosed in double quotes will not be expanded.
If a response file can not be opened, the argument is kept the same.
-Zargs-resp will automatically compile this in.
I reported one error with hbmk2.exe in os2gcc-OMF and now we know is due
hbmk2.prg are not managing our own object file extension and are relying
in default C compiler extensions
Use of .obj just exploited this situation
Is not case of os2gcc-OMF. Any other user may found the problem if
change object file extension for own purposes
I understand clearly because you explained it, this situation exist
because a feature/logic/structure of hbmk2: multiple input in place of
single input
What I see highly riskly in this case and your words/position, and you
are aware of it: Harbour are centering in hbmk2 features /logic
/structure, and not just centering but limited by them.
With your goals hbmk2 and at last Harbour "make" must be hard-wired to
default C compiler extensions and other decisions
hbmk2 is a beautiful piece of software with more than 7,500 lines of
code and well-known by you, but at last is a tool to help Harbour use,
not to re-direct him
Do not confuse: hbmk2 tool does not have to limit /manage the main
project: Harbour compiler
>2009-11-04 17:06 UTC+0100 Viktor Szakats (harbour.01 syenar.hu)
> * utils/hbmk2/hbmk2.prg
> * config/os2/gcc.mk
> * Changed to use GCC default extensions for objects and libs
> even in OMF mode.
> ! This fixed hbmk2 problems reported by David Arturo Macias Corona.
> ; Please verify if now also changed lib extension didn't create
> any new problem in hbmk2, f.e. when using -strip option.
This is an improper and arbitrary change but expected by your position
Against your own claim, you commited when your doubts are not cleared
and affecting entire OS/2 users
Simply you removed .obj and .lib for os2gcc - OMF even when I explained
they are "conventions" in OS/2 world
This must be consequence of report an problem with hbmk2 ?
Now you "dressed" an lib file with OMF content as an lib file with a.out
content
It confuse to any OS/2 user and will fail at first try
In OS/2 projects we look for .a files in a.out mode and .lib files in
OMF mode
I explained time ago that some projects release both types and there are
not conflict/collision due file extension
Only you know how you based your decision but it affect to OS/2 "community"
You do not need to be OS/2 user to understand this new problem
Your change fix a problem with hbmk2 reported by me opening an widest
problem as you can easily understand
That change must be reverted, at least for lib file extension
object file extension are of low importance as they are intermediate
files. But lib files are for end-users
You got your own conclusions and decided your change
Harbour developers will release OMF type lib files as .a files for OS/2
world ? It may be funny but is tragic and is evidence of lack of care
As other OS/2 projects we should release .a and .lib library files of
proper type
And in friendly words:
If you decide to revert your change, try to not to add your now typical
notes as: "I received false information", "as just copied", and so on
Is improper to see them in Changelog, including <"rogue" patch"> phrase
Again I suggest to follow:
> ... most of OS/2 projects style using .obj and .lib in OMF
To confirm default extensions in os2gcc-OMF I made some tests so they
can help to understand and rely your revert
Note: I am not being an C developer, I just adapted from OWatcom guide
Tests do not use file name extensions unless they are forced to avoid
error for existance
Process show dir in each phase so default extensions are easily seen
mytest.c
==================
#include <stdio.h>
void main()
{
printf( "Hello world\n" );
mytestlib();
}
==================
mytestlib.c
==================
#include <stdio.h>
void mytestlib()
{
printf( "Hello world from mytestlib\n" );
}
==================
mytest.cmd
==================
dir
gcc -c mytestlib.c -Zomf
dir
emxomfar r mytestlib mytestlib.o
dir
gcc -c mytest.c -Zomf
dir
gcc mytest.o -lmytestlib -Zomf
dir
mytest.exe
==================
and executing catching output:
[E:\mytest]mytest.cmd > mytest.out 2>&1
mytest.out content are below showing clearly default file extensions
David Macias
[E:\mytest]dir
The volume label in drive E is ECS20RC6A.
The Volume Serial Number is 2A6C:2415.
Directory of E:\mytest
5/11/09 3:05a <DIR> 0 ---- .
5/11/09 3:05a <DIR> 0 ---- ..
5/11/09 3:07a 98 0 a--r mytest.c
5/11/09 3:16a 154 0 a--r mytest.cmd
5/11/09 4:29a 0 0 a--- mytest.out
5/11/09 3:07a 100 0 a--r mytestlib.c
6 file(s) 352 bytes used
470,191,104 bytes free
[E:\mytest]gcc -c mytestlib.c -Zomf
[E:\mytest]dir
The volume label in drive E is ECS20RC6A.
The Volume Serial Number is 2A6C:2415.
Directory of E:\mytest
5/11/09 3:05a <DIR> 0 ---- .
5/11/09 3:05a <DIR> 0 ---- ..
5/11/09 3:07a 98 0 a--r mytest.c
5/11/09 3:16a 154 0 a--r mytest.cmd
5/11/09 4:29a 0 0 a--- mytest.out
5/11/09 3:07a 100 0 a--r mytestlib.c
5/11/09 4:29a 357 124 a--- mytestlib.o
7 file(s) 709 bytes used
470,190,080 bytes free
[E:\mytest]emxomfar r mytestlib mytestlib.o
Creating library file `mytestlib.lib'
[E:\mytest]dir
The volume label in drive E is ECS20RC6A.
The Volume Serial Number is 2A6C:2415.
Directory of E:\mytest
5/11/09 3:05a <DIR> 0 ---- .
5/11/09 3:05a <DIR> 0 ---- ..
5/11/09 3:07a 98 0 a--r mytest.c
5/11/09 3:16a 154 0 a--r mytest.cmd
5/11/09 4:29a 0 0 a--- mytest.out
5/11/09 3:07a 100 0 a--r mytestlib.c
5/11/09 4:29a 2,048 124 a--- mytestlib.lib
5/11/09 4:29a 357 124 a--- mytestlib.o
8 file(s) 2,757 bytes used
470,187,520 bytes free
[E:\mytest]gcc -c mytest.c -Zomf
mytest.c: In function 'main':
mytest.c:4: warning: return type of 'main' is not 'int'
[E:\mytest]dir
The volume label in drive E is ECS20RC6A.
The Volume Serial Number is 2A6C:2415.
Directory of E:\mytest
5/11/09 3:05a <DIR> 0 ---- .
5/11/09 3:05a <DIR> 0 ---- ..
5/11/09 3:07a 98 0 a--r mytest.c
5/11/09 3:16a 154 0 a--r mytest.cmd
5/11/09 4:29a 400 124 a--- mytest.o
5/11/09 4:29a 0 0 a--- mytest.out
5/11/09 3:07a 100 0 a--r mytestlib.c
5/11/09 4:29a 2,048 124 a--- mytestlib.lib
5/11/09 4:29a 357 124 a--- mytestlib.o
9 file(s) 3,157 bytes used
470,186,496 bytes free
[E:\mytest]gcc mytest.o -lmytestlib -Zomf
[E:\mytest]dir
The volume label in drive E is ECS20RC6A.
The Volume Serial Number is 2A6C:2415.
Directory of E:\mytest
5/11/09 3:05a <DIR> 0 ---- .
5/11/09 3:05a <DIR> 0 ---- ..
5/11/09 3:07a 98 0 a--r mytest.c
5/11/09 3:16a 154 0 a--r mytest.cmd
5/11/09 4:29a 4,752 0 a--- mytest.exe
5/11/09 4:29a 400 124 a--- mytest.o
5/11/09 4:29a 0 0 a--- mytest.out
5/11/09 3:07a 100 0 a--r mytestlib.c
5/11/09 4:29a 2,048 124 a--- mytestlib.lib
5/11/09 4:29a 357 124 a--- mytestlib.o
10 file(s) 7,909 bytes used
470,180,352 bytes free
[E:\mytest]mytest.exe
Hello world
Hello world from mytestlib
[E:\mytest]
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
