>So I made tests suspecting something. These are files length
containing
>only information within previous structure:
>3a.txt: 29,897 bytes gcc335, a.out, harbour.dll
>3am.txt 31,793 gcc335, a.out, harbourm.dll
>3o.txt 32,757 gcc335, OMF, harbour.dll
>3om.txt 34,653 gcc335, OMF, harbourm.dll
>3omu.txt 32,865 gcc335, OMF, harbourm.dll, one dir up
>First three build fine, while last two fail
>Each group are below and up of this limit:
> 2**15 = 2**(16-1) = 32768 bytes = 32 Kbytes
>Somewhere gcc is using 32 Kb limit for our case
> gcc --> emxomfld.exe
>( or is OS/2 limit ? :-) )
Recently new object files were added (593 vs 596)
hbascii
cpeliso
cptriso
harbour.dll exceded 32 Kb limit and does not build in OS/2-OMF
(gccomf, 3o.txt)
3am.txt are near to fail too
Now both harbour.dll and harbourm.dll does not build in gccomf due
mainly long strings used to reference directories/files exploited by
32 Kb limit
That's why I told that adding temp hack won't really help this
case. It's expected that we are getting more object files.
We've been also discussing about merging some libs in the
past, which IMO would still be a good thing, if this happens,
it will again cause problems with OS/2 bugs.
So, this seems like something to be fixed inside OS/2 GCC. Or
some new OS/2 specific hacks need to be implement to work it
around.
Brgds,
Viktor
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
