Hi Przemek,
> Use .a files just like .o ones and pass them to compiler as is. > It will now what to do with them. This is in SVN already. For -l I'm stripping all extensions, not just dll/so/a. Pls tell if this is a problem, and I'll solve it. > Yes it also supports it. DJGPP LD has also uses different initialization > order more similar to the one used by Windows/DOS C compilers. Okay, this was done. > 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. Okay, I'll add this as soon as Harbour gets the support. > > 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. ... > 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. Okay, thanks. Let me include here our conversation from autumn I was referring to, back then the situations looked cleaner than what it seems now: ---- 2008 november: -- vszakats says: Now I have to change the build process to use HARBOURFLAGSLIB and HARBOURFLAGSEXE instead of current HARBOURFLAGS and HARBOURFLAGSDLL, the difference between them is -n1 option vs -n. Executables should use -n, libs (.dll and .lib) should use -n1. -- druzus says: It's enough to add support for MAIN() as default startup function when non of functions is declared with HB_FS_FIRST and make all builds with -n1. We can also define that when MAIN() exists it's an application entry point instead of symbol defined with HB_FS_FIRST. It will have higher priority. In such case we can remove -n1 flag. Choose what you prefer and I'll implement it. -- vszakats says: I like the second one better, as it clears the ambiguity and even the requirement to use -n switch when someone defines MAIN(). So there would be one thing less to worry about. First choice however is more Clipper compatible, so IMO we should do it. -- druzus says: Please remember that current support for startup function is a hack which works only with few C compilers and even for them does not work correctly in all cases and we had to add yet another hack: -n1 switch which disable it for DLLs because DLL functions where registered before normal functions and 1-st dll function was used as startup one. Now we have two different behaviors which may cause portability problems for Harbour code and this is probably even bigger problem then strict Clipper compatibility. This problem cannot be resolved at compile time. To make it well we need linker wrapper which will extract first Harbour function from linked modules and mark it as startup one. I added such functionality to hb* scripts and this is the only one method which works in all conditions and does not dependent on the order of init code execution. Anyhow it works only for GCC. For backward compatibility with older Harbour code I gave main() higher priority then 1-st linked function but it can be removed. This feature exists for many years and works well. So far no one reported that it's a problem. I think it should be default for all platforms/C compilers. -- vszakats says: Okay with me. Any solution which closes platform, compiler, build-system differences is superior. It would be also nice to remove the hb* script hack if possible. -- druzus says: BTW If we want to keep -n1 then it should be changed to -n2 and simply -n1 should be the same as -n and -n0 should work like -n- to make it compatible with other switches. -- vszakats says: No, if possible let's please remove -n1 and keep only -n/-n-. ---- Brgds, Viktor
_______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
