Viktor:
You reverted my first commit in Harbour SVN age :-)
I hope this was an temporary action because content of code changes
are self-explained
I was based in doc\howtosvn.txt and this does not work in my case
6) svn commit --editor-cmd notepad.exe --username sfuser
( svn report missing log after using EPM OS/2 editor )
so I used Ryszard alternative
svn commit -F file_with_saved_ChangeLog_changes --username sfuser
Now back to your response, included entirely below to avoid quoting
parts
As you know I am in Harbour since February 1999 and seen the
"Harbour History" near allmost
So I know that one of your better personality characteristics is the
cooperative work and help to reach goals even if them are not yours
The hard part sometimes is that you reject until you understand it
entirely. Not allways is possible
So this is the spirit of your phrase:
"Please comment on the concerns and maybe we can find a
good solution,"
I as allways appreciate it and want to reach goals as you have seen
but this part tell me you are still confused :-) :
"like gcc4"
As this subject of OMF felt into a long chain of David/Viktor/
Maurilio unuseful messages, I moved from words to productive
actions, as commit to SVN
I am not an expert in OS/2 and/or os2gcc, but I am not a fool
Every message I posted is based in carefully checked/tested info
I started to test OMF/gcc335/gcc4xx since Oct 2008, and reported to
Harbour group in August 16 2009 "Harbour under OS/2 - eCS gcc",
first as long messages containing a lot of info, then summaries,
then diff output and last as SVN commit
But I do not want to get tired to anyone with this long list of
messages and explanations :-)
Based in all these works, I do not have doubts about we need to do
and I posted in summary. It imply os2gcc internals related to these
works
I understand clearly that you do not know os2gcc internals, and of
course you do not need to know every detail
I understand clearly that Maurilio do not know ALL os2gcc internals,
but can catch quickly what they mean. For sure is our OS/2 expert :-)
So when at first time a presented my work I was prepared to take
care of each of the questions/doubts that may arise by your part and/
or Maurilio, so them have answer in each message directly or
indirectly included in info presented
I supposed any doubts were solved :-)
but as ghosts some of them return many times and they avoid to add
benefits to Harbour capabilities
Since first message I added a lot of relationed info, enough to
clarify any doubts. One of them was reference and part of
svn.netlabs.org/libc/wiki/kOptions
(entire page is included below)
which start explaining:
"GCC on OS/2 supports several extra options. Most start with -Z.
With the exception of -Zomf (others?) they are affecting the linking."
so I explained many times with different words: "we need to tell
Harbour about an specific os2gcc feature"
and repeated: "we do not need gcc3/gcc4 separation"
My additional function is to save you or any other to work in
solutions which lead to unnecessary work, based in your (theirs)
remaining doubts
As I said: "subject is os2gcc library format types, not gcc3 vs gcc4"
Perhaps changing style from long messages to short explanations
(like FAQ) we can go faster:
- Why OMF ? Because is native to OS/2. os2-OWatcom default to OMF too
- And why we were using a.out ? Because it was only alternative when
OS/2 support was added to Harbour
- Why a.out is default in os2gcc: Because was only way available
when gcc was ported to OS/2. OMF support was added later with proper
implementation and unavoidable switch
- We need to drop a.out ? No, we can use either a.out or OMF
- What need Harbour to use OMF ? Just to inform him in some way
"hey, Harbour, build you in OMF type in OS/2"
- Needs for gcc ? Inform him to use OMF type (-Zomf) and optionally
set some os2gcc values
- Needs for Harbour ? Inform him to inform gcc to use OMF type and
set some values for Harbour
- Which values for gcc ? -Zomf and optionally EMXOMFLD_TYPE,
EMXOMFLD_LINKER
- Which values for Harbour ? Specification to use OMF (somebody
proposed HB_OS2_OMF) and corresponding values as .obj, .lib,
emxomfar, ...
- What are EMXOMFLD_TYPE, EMXOMFLD_LINKER ? Optional values which
inform os2gcc what to use to link. Defaults are VAC365 and ilink.exe
- And what are emxomfar.exe, emxomfld.exe ?
os2gcc use for:
+ a.out type: gcc, ar and ld
+ OMF: gcc, emxomfar and emxomfld. Emxomfld use as final linker
values specified by EMXOMFLD_TYPE, EMXOMFLD_LINKER, or defaults if
are not set
- We are forced to use wlink ? No, is optional. User can apply other
prefered final linker
- Which final linker is suggested ? Harbour with OMF support has
been tested with LINK386.exe and WL.exe. First have many limitations
explained in messages and WL.exe gave best results. WL.exe is an
modified OpenWatcom WLINK.exe to add support of debuggers in HLL
format
- Which are benefits for Harbour adding OMF ? Enhance Harbour-OS/2
adding possibilities to use native format and newer gcc compilers.
Is specific to OS/2. Harbour can use an ported type (a.out) and a
native type (OMF)
- May I use gcc335 ? Yes, gcc335 support both a.out and OMF types
- Can I use gcc4xx ? Yes, gcc4xx support OMF type
- Why gcc4xx does not support a.out ? Because a problem with an old
tool (emxbind) used to manage a.out type in OS/2
- gcc335 will be droped in Harbour ? No, it can continue working as
ever
- And what happen if Harbour does not add support of OS/2 OMF ?
Harbour will remain attached to older os2gcc and non-native a.out
library format
- Is hard to add support of OS/2 OMF to Harbour ? Is very easy
- Adding OMF support will affect to Harbour ? No, in any sense
- Adding OMF support will affect to Harbour users ? No, in any sense
As on other platforms/compilers proper settings are responsability
of end-users
- ...
and this type of FAQ can be growing and at last may recall so same
confutions :-)
Note: In exercise of FAQ nothing was new info, all belong to old
messages
Another potential problem you sketched: collision of version files
- .o vs .obj: does not happen
- .a vs .lib: does not happen
- .dll vs .dll: it happen. Is a problem ? have same content ?
- implib: a.out create harbour?.a and OMF create harbour?.lib
- ...
As explained many times, in my local directories Harbour have
support of OMF library type and near everything is working fine, as
a result of all works made to include that support
As a good surprise I repeated: changes are minimal and
implementation are very easy
Yes, I found and explained why harbourm.dll is failing in OMF type,
but is a minimal case which must not to stop rest of work
Of course, as in past cases, I am trying to find solution
And for "HB_OS2_OMF": since beginning I requested for a way to "tell
Harbour to tell os2gcc to use OMF type" and I suggested an
environmental variable
So for me:
HB_ : belong to Harbour
OS2_ : is specific os2gcc value
OMF : tell to os2gcc to use OMF type in Harbour
We can talk of this value as "switch", variable, "control setting",
"knob" or else. Is used to specify something to Harbour which will
specify to os2gcc
If the choice is "environmental variable", it can be named as
HB_OS2_OMF, HB_MYNEWIDEA, HB_ANYTHING, ... We what just the function/
purpose
About your proposal "HB_COMPILER=gcc4": is not matter of os2gcc
release, is matter of library type so is improper to create two gcc
versions
This kind of confutions/doubts is what I am trying to avoid
Is not hard to mantain HB_OS2_OMF or something as it
Until now we only need in two areas:
- To build Harbour: gcc.mk
- To build programs made with Harbour: hbmk2.prg
We can keep it limited
And believe me, solution I posted in SVN is, changing word "easy", a
__proper__ solution
Why ?
- gcc335 can be used as ever, as a.out remain as default
- gcc335 can be used in OMF
- Harbour immediatly jump to gcc4xx support without additional
changes and without compiler releases separation
- and clearly, is os2gcc specific
It does not hurt anyone, and specially Harbour development
Of course, a little of info in INSTALL may help
As allways I will keep open to alternatives,
I just landed some in SVN so any potential Harbour-OS/2 user can
test/apply them immediatly, and not just me locally
For sure if are not proper they can be changed easily as you know
And for sure any idea you present in code form I can test immediatly
in real OS/2 environment. We can left out words and go to actions
I am certain of two things:
- Any alternative you present will be longer than mine because I
presented only which os2gcc need to know, and Harbour need to manage
- You will see that is not too much what we need
As I said, that was my surprise: is very easy to add this feature
David Macias
svn.netlabs.org/libc/wiki/kOptions
GCC on OS/2 supports several extra options. Most start with -Z. With
the exception of -Zomf (others?) they are affecting the linking.
* -Zcrtdll: link the C library dynamically
* -Zdll: create a dynamic link library
* -Zexe: create foo which is executable which calls foo.exe which
is also created.
* -Zhigh-mem: link so that the C library calls in the program
make use of "high memory". This is similiar to specifying OBJ_ANY to
OS/2 API memory calls. If you use this option you should include
os2safe.h as the first include file in every C file that uses OS/2
APIs.
* -Zlinker: pass option through to linker (like -Zlinker /EXEPACK:
2 -Zlinker /PACKCODE)
* -Zmap: tell linker or emxbind to create a .map file that
contains the addresses of all symbols
* -Zno-autoconv: switch off automatic conversion between a.out
and OMF format when linking.
* -Zautoconv: switch on automatic conversion between a.out and
OMF format when linking.
* -Zomf: compile and link using OMF format instead of a.out.
* -Zargs-wild: call _wildcard() (see below) automatically on
startup
* -Zargs-resp: call _reponse() (see below) automatically on startup
* -Zdll-search: Enables dlls as valid libraries. (default disabled)
* -Zsym: Invoke mapsym.cmd on the mapfile to produce a .sym file.
Requires -Zmap
These may not be OS/2 specific
* -Bstatic, -non_shared, -dn, -static: Link with static libraries.
* -Bshared, -call_shared, -dy: Link with shared libraries.
(default)
These are mentioned in ReleaseNotes?.os2 but not sure what they do
exactly:
* -Zhigh-low: ??
* -Zno-fork: turn off the fork() function?
* -Zno-unix: non-unix like mode, affects slash handling and fork()?
These were supported options with EMX/gcc 2.8.x, not sure if they
are still supported now:
* -Zbin-files: open files in binary mode by default (still
supported)
* -Zbsd-signals: select the `BSD' signal processing model
* -Zmt: multithread code (now default)
* -Zmtd: multithread code, link C library dynamically
* -Zmts: multithread code, link C library statically
* -Zno-rte: create DLL without runtime environment
* -Zsmall-conv: use small, fast, and inaccurate routines for
converting decimal numbers to binary and vice versa
* -Zstack: set the stack size
* -Zso: create stand-alone DLL
* -Zsys: create stand-alone OS/2 program (no emx.dll) - there's
nothing similar for current libc, if you use new gcc with new libc,
you always need the libcxxx.dll
* -Zsysv-signals: select the `System V' signal processing model
There are also various environmental variables that affect the
linker type. (from the output of emxomfld 0.6.3)
Environment variables:
EMXOMFLD_TYPE:
The type of linker we're using. Values: WLINK, VAC365,
VAC308, LINK386.
WLINK wlink.exe from Open Watcom v1.5 or later. VAC365
ilink.exe from IBM C and C++ Compilers for OS/2 v3.6 or later.
VAC308 ilink.exe from Visual Age for C++ v3.08. LINK386 link386 form
OS/2 install or DDK.
EMXOMFLD_LINKER:
Name of the linker to use and optionally extra parameters.
Spaces in the linker name or path is not supported. Quotes are not
supported either.
The default values for these two variables are VAC365 and ilink.exe.
EMXOMFLD_RC_TYPE:
The type of resource compiler we're using. Values: RC,WRC.
RC rc.exe as shipped with OS/2 or found in the Toolkit
WRC wrc.exe from Open Watcom v1.6 or later.
EMXOMFLD_RC:
Name of the resource compiler to use and optionally extra
parameters. Spaces or quotes in the name or path are not supported.
The default values for these two variables are RC and rc.exe.
Finally, there are a couple of special functions which simplify
porting of Unix programs:
* _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 guess you'll have to write more precisely.
You wrote "no new value in Harbour build scheme".
If you meant "no new control setting", or "no new environment
value" (as Alex suggested), you're absolutely right. Since
I'm working to REDUCE number of control knobs, I don't want
to add new ones for no good reason. I'm sorry if you
can't grasp the benefits of this direction. See below a
little explanation:
Every such knob needs to be documented, maintained, kept
working. Besides each of these knobs will have to be
understood by users, and we as developers will have to
support them in this. Each of these knobs will have different
branches inside the make system also to _test_. Each of these
extra knobs adds to the complexity of the design, which
means each of these "simple" and "easy" solutions will turn
out to cause much more trouble on the long run, than you're
saving on the design side. That is why creating a simple
design is in fact much complicated than a messy one. [ Plus
one: This specific extra know will have to be carefully
synced by user to the gcc environment he uses. This is not
obvious from the knob's name "HB_OS2_OMF", which suggest
this is a general option to choose object format, but this
is just one little issue with such design. ]
So, I don't like them. We still have such knob for MSVC
which sets some internal details depending on MSVC version.
I don't like it either, and I certainly wouldn't like to
duplicate such bad solution.
Please comment on the concerns and maybe we can find a
good solution, like gcc4, which you can't tell why you
don't like, or autodetection of non-OMF vs. OMF environment.
Although this again goes best with gcc4 solution to keep
internal logic clean. Notice there are solutions to avoid
.mk logic duplication even in this case (just change
HB_OS2_OMF=yes checks to HB_COMPILER=gcc4 checks). Granted,
it needs a little more work to complete, since gcc4 needs
to be introduced to a few places.
[ As for the wlink hack (two extra knobs), it's so marginal
that IMO we should just drop it. And every word spent on
discussing it just time wasted. If you want to experiment
with it locally, just create a new compiler .mk file ]
Plus we stil have the cmdline problem, which isn't solved
yet properly, so that gcc4 becomes ready for SVN. Maybe
it's not the "easy" way, but in Harbour we value the
_proper_ way, instead of the "easy" one.
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
