Note warning for protmode in harbour.dll

Probably caused by PROTMODE keyword.

Reading info I used "p" parameter for make.exe which describe a long
list of values/operations used in current make proccess. It show a lot
of redefinitions
The intention was to limit list of libraries included in order to find
the "possible" object file causing error
I never found where to change this library list, and specially for mt

Never found LIBS definition for this expression:
 DLIBS := $(foreach lib,$(LIBS) $(SYSLIBS),-l$(lib))
and suppressing it nothing change

LIBS is optional, if it's not used for os2/gcc, it's not a problem.
Although we may explicitly empty it from global.mk.

Note: using $(DYNNAME) does not include .dll extension, so I suppose it
is added by default and not due Harbour definitions
  @$(ECHO) LIBRARY $(DYNNAME) INITINSTANCE TERMINSTANCE >> __dyn__.def

DYNNAME is the raw name, without any platform specific
decorations. Anyhow $(DYN_EXT) contains the extension,
so it can be added if needed, in this case though I think
it's denoting the internal lib name, so the extension
may not be necessary.

Question: why source\dynlib\Makefile include line
  include $(TOP)$(ROOT)config/dir.mk
and not are included in source\dynlib\mt\Makefile ?

dir.mk is only needed if we want to pass control to
subdirs, in ST we pass it to MT, but MT is the last
one, so there is no dir.mk, nor DIRS variable.

Spliting section for harbourm.dll have exactly the same form. The only
differences are:
- "..\..\..\..\..\..\" in place of "..\..\..\..\..\"
- "vm\vmmt\" in place of "vm\"

Yes, this can explain extra space needed for mt dll,
it's one level deeper, so each obj is addressed using
an extra ../, that is a few Ks extra in cmdline.

I tried to build harbourm.dll using a directory in same level of dynlib,
for example "source\mydyn", suppresing "source\dynlib\mt", using
Makefile for "source\dynlib\mt" moving up one dir, and adjusting
Makefile for "source"
Results was an harbourm.dll with exactly the same length as harbour.dll
  :-) (?)

You also need to change DYNDIRLIST (copy it from source/dynlib/mt/ Makefile)

So I changed test:
- Move source\dynlib\mt\obj\os2\gcc\__dyn__.tmp, .def files one dir up,
to source\dynlib\mt\obj\os2\__dyn__.tmp, .def files
- Change in __dyn__.tmp "..\..\..\..\..\..\" with "..\..\..\..\..\"
- Execute gcc for harbourm.dll using a dir up:
gcc -Zomf -shared -L../../../../../lib/os2/gcc  -o
../../../../../bin/os2/gcc/harbourm.dll @__dyn__.tmp __dyn__.def - lsocket

and harbourm.dll build fine, with different size than harbour.dll
Same warning for protmode in harbourm.dll

So the reason for emxomfld failure is due to length of long list of
object files in section:

--------------------------
..\..\..\..\..\..\source\common\obj\os2\gcc\expropt1.obj

[rest of .obj files list]

..\..\..\..\..\..\source\vm\vmmt\obj\os2\gcc\vm.obj
--------------------------

This harbourm.dll list is longer than harbour.dll list by a value of:
"..\" length multiplied by number of total object files plus
"vmmt\" length multiplied by number of vmmt object files

3*593 + 5*21 = 1779 + 105 = 1884 byes

so seem to arrive truncated to emxomfld.exe and cause "invalid argument"
error
Moving up one dir resolve need of at least 1779 bytes plus others for -L and -o switchs

Yes.

Viktor, Maurilio, Przemek:      
any idea to overcome this limit ?

I hope so, otherwise we'll have to restructure dir layout for
the sake of OS/2 to an uglier one. I'd like to avoid doing this.

Brgds,
Viktor

_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Reply via email to