On Sun, 09 Nov 2008, Szak�ts Viktor wrote: Hi Viktor,
> I've tried to add hbrun_dll, but I got all sort of > unresolved external (tested with BCC and MSVC). This > may be due to the fact that the symbols are declared > without HB_DYNLIB in hbcplr.lib, while we'd like to > link with harbour.lib where those are declared HB_DYNLIB. No. EXPORT attribute is necessary only for functions which will be accessed externally by name (directly in source code and bound by linker or indirectly by GetProcAddress() at runtime. In this case non of symbol is accessed in such way. > A while ago some local tests showed that enabling > HB_DYNLIB by default is in fact causing bigger final > executables (tested with MSVC), so I didn't commit > anything in this regard finally. The generated code > looks the same, so speed doesn't seem to be affected, > and maybe there is a link switch to exclude the extra > information cause the size increase, I'm still looking > into this. Exporting symbols causes that binaries contains table with symbol name and its address. The size overhead is caused by this table. It's possible that some tools can strip this table from final binaries or some linkers have such option. But it's not related to hbrun_dll problem. If hbtest_dll works than hbrun_dll should work too. Probably you not added COMPILER_LIB to library list. hbcplr is not part of harbour shared library so static version have to be used. best regards, Przemek _______________________________________________ Harbour mailing list [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
