Hi David,
>[ Other option is to rename os2/gcc to os2/gcc3
>and add new 4.x OMF support as os2/gcc. Depends
>on which one OS/2 users think is best to have
>as "default". ]
This lead immediatly to mantain two versions, gcc3 or gcc4, and is
inadequate. As Maurilio said, we are short of resources
Changes for support a.out and OMF are minimal and can be managed
easily in gcc.mk, hbmk2.prg as I am doing now and explained in summary
I don't know, if you ask me both solution give much extra
work to maintain, and the extra switch is even inelegant.
Probably OS/2 users should come to conclusion which gcc
version should be supported in Harbour and invest all time
and energy into that.
Both maintaining two gcc.mk files and adding OS/2 specific
hacks to hbmk2 and the make system seems like giving even
more continuous efforts to maintain OS/2 port, and I envision
most of such effort will have to invested by me. So, sorry
if this sounds rude, but I don't like either ideas.
>Can you define "perhaps" here?
libcxyz.dll are GCC runtime for different gcc versions/releases
They are usually specified as necessary for some program, so maybe
the last survivor (OS/2 user in Hungary) have it installed previously
Now I have these (I deleted others):
------------------
14/04/04 4:37p 356,330 0 a--- libc05.dll
11/06/07 10:53p 48,142 0 a--- libc06.dll
11/06/07 10:53p 48,142 0 a--- libc061.dll
11/06/07 10:53p 157,124 0 a--- libc062.dll
5/09/06 8:51a 929,002 0 a--- libc062x.dll
11/06/07 10:53p 1,349,060 0 a--- libc063.dll
------------------
For example, notes for Firefox stated:
------------------------------
The GCC runtime is required; download that at ftp://ftp.netlabs.org/pub/gcc/libc-0.6.3-csd3.zip
(zip file), ftp://ftp.netlabs.org/pub/gcc/libc-0_6_3-csd3.wpi
(WarpIn archive), or ftp://ftp.netlabs.org/pub/gcc/libc-0_6_3-
csd3.exe (a self- extracting executable). The GCC runtime installer
defaults to x:\OS2\DLL (where x is your OS/2 or eComStation boot
drive); it may be preferable to put the runtime in the same
directory as the Firefox executable, or in x:\ECS\DLL (which is
where I have it on my eComStation machine).
------------------------------
:$ I'll add link to the first .exe you listed.
From http://warpin.netlabs.org
------------------
WarpIN is intended to become the new general-purpose installer
for OS/2 to overcome the current lack of a both flexible and user-
friendly installer.
------------------
Just like Windows Installer, RPM installer, ...
Thank you.
As I said in previous message:
-------------------------------
Note for Viktor: In current SVN there are not any reference to
HB_OS2_TCP32. It gone when make_gnu_os2.cmd was deleted
I still use it and maybe Maurilio will use it if upgrade his OS/2
-------------------------------
I know, but since all starter batch files got deleted, so
were the comment.
This subject caused years ago a long discussion between Maurilio and
me ( as a.out/OMF and/or gcc4xx is causing now :-) ) and Przemek
pacified it introducing HB_OS2_TCP32
So a new switch can be introduced too :-)
IMO one extra switch to control to other generic ones
doesn't really justify the maintenance of the former,
so IMO we're now just fine.
I'd think that by now there should be a default which
suits _most_ OS/2 users ;)
------------------------------------
rem In GCC3.2.2 the TCP/IP headers and libraries scheme have been
changed.
rem The default is the current OS/2 tcpip toolkit (BSD 4.4 based).
rem To target the older OS/2 tcpip stack (BSD 4.3 based) and create
rem binaries which can be executed also on older OS2 versions you must
rem define TCPV40HDRS before including any TCP/IP headers and make
rem sure usr/lib/tcpipv4 is searched before usr/lib (this is to
rem get the right libsocket). It is recommended to use the -D
rem compiler option for the define and either the LIBRARY_PATH or
rem the -L compiler/linker option for the library.
rem For building Harbour you can also use HB_USER_LDFLAGS
environment variable,
rem f.e.
rem set HB_USER_LDFLAGS=-Le:\usr\lib\tcpipv4
rem
rem If you are using newer OS2 version with tcp/ip stack >= 4.1
rem (eComStation, for example) and you do not need backward binary
rem compatibility then you can disable it by setting HB_OS2_TCP32
rem environment variable, f.e.
Yes, I know this text, but for me it doesn't tell anything
meaningful. For me the most important thing here is what are the
real-life chances some users want to choose this or the other.
And setup the default in a way to it won't require any fiddling
with this for most users.
A new specific OS/2 switch/environmental variable and use/changes in
gcc.mk / hbmk2.prg will put to work OS/2 in a.out/OMF, gcc335/gcc4xx
alternatives
After all I am doing it and is very simple
Note: "new specific switch for OS/2" is ONLY to choose library
format between a.out and OMF, and NOT for choose gcc335/gcc4xx.
Later does not need to be specified and is stated/autodetected based
in path
I don't like it.
With the switch solution it would be extremely easy to mess up a build
by forgetting to set or unset the switch depending on gcc version used,
or using lib files coming from the other version of gcc. HB_COMPILER
should denote _compatible_ targets, in this case this would no longer
be true.
Since we're talking about totally incompatible GCC setups, the distinct
names seems to me absolutely justified.
Anyhow even those would require extra work, which I just don't feel
justified either.
Again:
gcc335 support a.out and OMF. Harbour historically "ONLY know" a.out
gcc4xx support OMF. Does NOT WORK a.out because a problem with emxbind
So because of a bug, the object format needs to be changed?
IMO, Harbour OS/2 users should choose gcc3 OR gcc4 as the
supported OS/2 compiler for Harbour, and we should then
concentrate on that.
I personally wouldn't pay the price in extra work just to give
one more extra and incompatible option for OS/2. Support already
is enough of a maintenance burden.
So to state different os2\gcc3 and os2\gcc4 is UNNECESSARY
OS/2 Harbour origins were based in emx/gcc(281,295?) environments,
limited, and later replaced by enhanced gcc335. I was using gcc
(281,295?), Harbour stop to build, and Maurilio explained me to use
"newer gcc335" many years ago. Is time to go ahead with gcc4xx
introducing at same time the option to use a.out or OMF
Other note:
Perhaps OS/2 Hungarian user need emx runtime too (emx.dll, emx 0.9d)
if using a.out type
As I have it (x:\emx\) since around 10-12 years ago, I am not sure
if it is need for gcc335/a.out
I hope he reads these lines!
Brgds,
Viktor
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
