On Mon, 08 Jun 2009, Szak�ts Viktor wrote: > > I think that you should also add an option to disable adding standard > > harbour libraries when DLL is linked. It will help to locate used functions > > missing in hbmaindllp at link time. Otherwise user can still create wrong > Okay, I understand that. (-nohblibs f.e. which could work in all modes)
It should be enough. > [ But, can't wholeheartedly endorse the concept of hbmaindllp, it looks > like an ugly and incomplete kludge. So I'm not sure we should use > hbmk2 to find out what's missing from it. Could be I'm misunderstanding > the purpose. ] I do not understand. hbmaindllp makes exactly what it should and makes it well though in my opinion it should be moved to separate directory and divided into few files. The main files should conatin only hb_vmExecute() and hb_vmProcessSymbolsEx(). Only these two function are necessary to create .DLL with .prg functions compiled with -gc2. Wrapper for other functions (if any) should be added inb seprate files. F.e. dllxvm.c with functions necessary for -gc3 code, dllext with extended API functions, etc. > > binaries. I think that you can simply bound it with -shared option. > > When -hbdyn is used and static DLL is created then you can use hbmaindllp > > instead of standard harbour static libraries. Otherwise when -[fix]shared > > switch is used explicitly then you can enable linking with harbour.dll > If I understand correctly this means a new 'neutral' mode which is neither > shared nor static. Forget about it. -nohblibs will be enough. If user does not understand what he should do then he should not make it at all. best regards, Przemek _______________________________________________ Harbour mailing list [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
