On Thu, 19 Feb 2009, Szak�ts Viktor wrote: Hi,
> Right now every filename passed as is (without -l) with the > extension .a is considered a library. Would it help if hbmk would > simply handle .a files just like object files? This would mean > that libs with .a ending must have to be passed with -l to make > it handled like a library. Use .a files just like .o ones and pass them to compiler as is. It will now what to do with them. > Okay, and also djgpp, as per its .cf file. Yes it also supports it. DJGPP LD has also uses different initialization order more similar to the one used by Windows/DOS C compilers. > > yes, and the conclusion was that we can remove it when we will have > > hb* tool which can set information about 1-st symbol for HVM at link time. > > If you do not want to extract this symbol from source code or object > > files then as alternative you can enable in compiler setting HB_FS_FIRST > > only for one compiled file (the 1-st one) so we will have only one > > symbol registered in HVM with this flag. > Can we have a harbour compiler flag for this? We will _need_ such flag and hbmk2.prg will enable it to compile the first file only. If more then one .prg file is given then harbour compiler will reset this flag after compilation the 1-st one so only this file will have HB_FS_FIRST set. > If I understand correctly, currently we have -n which > makes a FIRST for all compiled .prgs, and we have -n1 > which disabled FIRST for all compiled .prgs. Perhaps > we should have another flag to enable FIRST only in > the first .prg. No. We have -n for compatibility with Clipper -n parameter. When it's used harbour compiler does not automatically generate procedure with the same name as file name. HB_FS_FIRST is added independently to mark 1-st public function/procedure in generated code. In fact it's redundant because we can guess where compiler should set it using combination of other flags but it does not change anything for us. Such detection of startup procedure cannot work well because it depends on unpredictable for us linker behavior. But it was working for most of windows linkers so HB_FS_FIRST was added and used. But only in basic cases and it was still out of our control when it can stop to work as expected. Such situation happened when users begins to use .DLLs with PCODE functions. DLLs startup code was executed before the startup code in user object files and HVM begins to execute wrong functions marked as HB_FS_FIRST from DLL module instead of user ones. So as workaround for workaround -n1 one was added. -n1 switch disables setting HB_FS_FIRST and it's only Harbour extension unsupported by Clipper and windows users use this switch when they want to create .dll with PCODE modules. best regards, Przemek _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
