Przemek:
I am including below warnings raised using gcc440, 432 and 433
Some are known. Rest should be fixed ?
>Thank you for your tests. I think we should leave some information
>about it for OS2 users who want to use newer GNU make ports.
I exceded usual info/details in messages with purpose to serve
immediatly to anybody who want to test
At end of my tests I will made a summary which can be included in
INSTALL, for example
>probably you will have to pass it as linker option, maybe using
>-Wl,<option>
>I do not know -Zlinker is not standard GCC option.
>Maybe you can also take linker (LD) from older GCC builds which worked
>for you.
I made many tests
In order to exclude "DEBUG HLL" forcing strip_symbols we have to use "S"
parameter in emxomfld.exe:
----------------------------------
Usage: emxomfld -o <file> [-l <lib>] [-L <libdir>] [-T <base>] [-igtsS]
[-Zexe] [-Zdll] [-Zsym] [-Zstack <size>] [-Zmap[=<map_file>]]
[-Z[no-]autoconv] [-Zdll-search] [-O <option>] [-static]
[-non_shared] [-Bstatic] [-dn] [call_shared] [-Bshared]
[-dy] <file>...
----------------------------------
But emxomfld.exe can not be called directly
See some extract of messages related:
----------------------------
If you compile with -Zomf, then you should use emxomfar and emxomfld
(the latter is invoked automatically when you use gcc -Zomf to link)
If you compile without -Zomf, then use ar and ld
---
You can't just use ar and emxomfar interchangeably without
recompiling. emxomfar works only with OMF files, ar with a.out
---
Yes, emxbind. However, it's much easier to have gcc invoke it for you.
In order to do that, you should set the output of the link step
to e.g. flex.EXE; the exe extension causes gcc invoke emxbind
to create an OS/2 executable.
Most makefiles of ported software are written in Unixish way:
no exe suffix. -Zexe can be used to "fool" the makefile
(that's why it creates a file 'flex'; make checks for the
existence of that file).
If you compile with -Zomf, gcc uses emxomfld to do the linking.
emxomfld is just a frontend for LINK386, and it always creates
an OS/2 executable.
----------------------------
In our case we are using OpenWatcom WL.exe in place of LINK386.exe which
show many limitations
As using
gcc -Zomf ...
call emxomfld.exe for linking, we can not use "S" parameter
emxomfld.exe which is called by gcc is an wrapper for our final linker
(LINK386, WL(INK), ILINK, ...), and parameters sent with -Zlinker and/or
"SET EMXOMFLD_LINKER parameters" are for final linker
So we can not send "S" to emxomfld.exe
If I use emxomfld.exe directly in place of gcc.exe, with proper
adjustments for parameters, it raised a lot of warnings/missings
building Harbour binaries
And we can not use LD.exe because precisely part of trick is to exclude
ar/ld to use OMF type in place of a.out type
Until now Harbour is building entirely with
gcc440: Build time: 53 minutes
gcc432: Build time: 35 minutes
gcc433: Build time: 35 minutes
Question: Which gcc version do you recommend to use as prefered compiler
for Harbour-OS/2 ?
Perhaps gcc440 is too new and a best choice can be gcc433
Mandriva 2008.1 are using gcc423 and Mandriva 2009.1 are using gcc432
Additionally:
Using LINK386.exe as final linker we have:
-------------
E:\harbour907h\harbour\lib\os2\gcc\hbextern.lib(hbextern.o) : fatal
error L1046: too many external symbols in one module
From Tools reference:
www.warpspeed.com.au/cgi-bin/inf2html.cmd?..%5Chtml%5Cbook%5CToolkt40%5CTOOLSREF.INF+660
L1046 too many external symbols in one module
Explanation: An object module specifies more than the limit of 1023
external symbols.
Action: Reduce the number of external symbols, breaking the module into
smaller parts, if necessary.
-------------
Here we exceded limits at linking
As we have a pending problem with OpenWatcom/hbrun.exe which GPF due
hbextern.lib as tests confirmed, I am thinking if it is time to split
hbextern in more modules to have less symbols per module
What do you think ?
David Macias
[E:\harbour907h\harbour]make -r -w 1>make_gnu.log
../../../filesys.c: In function 'hb_fsSetFileTime':
../../../filesys.c:1145: warning: 'ftime.twosecs' may be used
uninitialized in this function
../../../filesys.c:1145: warning: 'ftime.minutes' may be used
uninitialized in this function
../../../filesys.c:1145: warning: 'ftime.hours' may be used
uninitialized in this function
../../../gtos2.c: In function 'hb_gt_os2_Redraw':
../../../gtos2.c:799: warning: pointer targets in passing argument 5 of
'pGT->pFuncTable->GetScrChar' differ in signedness
../../../gtos2.c:799: note: expected 'BYTE *' but argument is of type
'char *'
../../../gtstd.c: In function 'hb_gt_std_ReadKey':
../../../gtstd.c:412: warning: unused variable 'TODO'
../../../sqlite3.c: In function 'sqlite3_os_init':
../../../sqlite3.c:20798: warning: initialization from incompatible
pointer type
[E:\harbour907h\harbour\bin\os2\gcc]harbour /build
Harbour 2.0.0beta2 (Rev. 12104)
Copyright (c) 1999-2009, http://www.harbour-project.org/
Harbour Build Info
---------------------------
Version: Harbour 2.0.0beta2 (Rev. 12104)
Compiler: EMX GNU C 4.4 (32-bit)
Platform: OS/2 4.50
PCode version: 0.2
ChangeLog last entry: 2009-08-14 11:24 UTC+0200 Viktor Szakats
(harbour.01 syenar.hu)
ChangeLog ID: ChangeLog 12104 2009-08-14 09:31:12Z vszakats
Built on: Aug 15 2009 18:26:04
Extra C compiler options: -DTCPV40HDRS -DHB_FM_STATISTICS_OFF
Extra linker options: -Le:\usr\lib\tcpipv4
Build options:
Language options: (Clipper 5.3) (Clipper 5.x undoc) (Xbase++) (Flagship)
---------------------------
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
