Hi David,
Downside is that the exact way these tools need to be called will
have to be checked. Since OS/2 is a pretty static system, it's
probably enough to do it once (and maybe once again for gcc4) and
we're good.
I insist in keep it simple and just to make minimal changes
It is not necessary to change actual behaviour in big extent
For a.out os2gcc use gcc, ar, ld
For OMF os2gcc use gcc, emxomfar, emxomfld
OMF problem is not due gcc4, but without OMF support, Harbour can not
upgrade to gcc4
I made entire tests with gcc335 and gcc4xx using:
* $Id: ChangeLog 12624 2009-09-28 20:51:46Z vszakats $
2009-09-28 22:27 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
Remember, we have two situations and I am dealing with both
a) Support of Harbour OMF type, for gcc335 and gcc4xx
b) Support of Harbour gcc4xx
Results:
- Harbour build entirely with any mode, compiler with minimal changes
- gcc335: work entirely in a.out mode, including .dll files
- gcc335: work near entirely in OMF, except harbourm.dll (*)
- gcc4xx: work near entirely in OMF, except harbourm.dll (*)
(*) Harbourm.dll, as explained, does not build due emxomfld.exe limit
and emxomfld.exe is an gcc335 tool used by gcc4xx too
I moved based in Viktor guidelines source\dynlib\mt to source\dynlibmt
directory, deleting source\dynlib\mt lib and making proper changes in
source\dynlibmt\Makefile and source\Makefile
So harbourm.dll and harbourm.lib build fine with either a.out or OMF
I do not see great challenge to Harbour to change
"source\dynlib\mt" to "source\dynlibmt"
I do not expect other platforms, compilers to have damages :-)
I don't plan to do it. The reason is two-fold, first it makes
the layout messy, second this solution can only solve the problem
temporarily. Sooner or later we will have additional objects which
are part of .dlls, and in this case it will just break again,
for both .dlls.
So I suggest to solve the root cause instead of adding such
workaround.
If someone want to build Harbour with gcc335/OMF type or gcc4xx/OMF
type, just need to set:
set EMXOMFLD_TYPE=WLINK ( or prefered choice )
set EMXOMFLD_LINKER=WL.EXE ( or prefered choice )
set HB_OS2_OMF=yes
With current diff output and moving "source\dynlib\mt" all work is
done
Thanks for the patch, but sorry, I still don't support this
method for reasons described multiple times. It's an
out-of-the-band bunch of options, so for me it's still in
the hack area. I also don't understand why to introduce
additional EMXOMDLD_* variables. I'm trying to REDUCE
number of control variables and to keep the main logic as
straightforward, simple and portable as possible, this
patch goes to the other direction.
Brgds,
Viktor
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
