Hi Przemek, (answers part 2)
> > > 8. When -l<libname> gcc option is used then <libname> should > > > not contain prefix (lib) and extension (.so,.dll,.a) > > > > hbmk does pass the stripped lib name to gcc -l option > > already. The extension is already stripped (all of them, > > maybe that's too harsh?). So if I understand you correctly > > the 'lib' prefix should be stripped, too? In that case, isn't > > that dangerous for libnames like "liblibcurl.a" when the > > user supplies libcurl, we will have an invalid name. > > hbmk2.prg should not make any modifications in *.a parameters > but pass them to GCC as is because GCC uses in different way > .a archive passed directly then -l<libname> option. In the 1-st > case for GCC it's only archive with object files which can have > any name and can contain the path, f.e.: > gcc ... mydir/myobjs.a > in the second case its library which have to be located in one > of system library paths (or specified by -L option) and need name > which confirms platform dependen't naming convention. In most of > case it 'lib' prefix and valid sufix ( .a, .so, .dll, .sl, ... ) > The link precedence and rules used to overload symbols are also > different. Sometimes this difference is important if you want to > overload some library functions, f.e. customized getsys in Harbour > core code but also some system libraries. To make things more > complicated it also depends on -Wl,--start-group / -Wl,--end-group > options and used LD. 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. > > > 9. We should have support for passing object archives (.a) in > > > link file list and then pass it to GCC without -l parameter. > > > Using 'mylib.a' and '-lmylib' as GCC parameters has different > > > meaning so mylib.a should not be converted to -lmylib but simply > > > passed to GCC as is. > > I have to think about this one. Should be done, no question, > > but I'd like to better understand. What the difference between a > > mylib.a as object archive and a mylib.a as lib? Should these > > non-lib .a files be supported through .hbp files? We will need > > a separate option for it then. > > See above. > > > > 10. In GCC builds on platforms which support > > > -Wl,--start-group <HARBOUR_LIBS> -Wl,--end-group > > > (linux, mingw) we should use it to not replicate libraries with > > > cross bindings. > > > BTW current library list is not well ordered so it's not possible > > > to create some binaries, f.e. try hbmk hbrun.prg in some GCC builds. > > > It has to be updated for platforms which does not support above > > > library grouping. > > I was thinking about this, but didn't reach this topic yet. > > -Wl seems easy to add, but I don't know which platforms > > support it and which not (mingw does support it for sure). > > MinGW and Linux. Okay, and also djgpp, as per its .cf file. > The rules are very simple: > libraries are scanned for necessary dependence but after scanning it > LD does not return to this library and begins to scan next one. > If next library contains references to symbols which exist in previous > one and was not necessary so far then you have to repeat the previous > library after currently scanned one. library grouping creates a set > of libraries in which LD returns to previous ones so you do not have > to repeat them. > Doubling library list is also not real solution in all cases. You can > easy create situation when it's necessary to repeat the same library > 3, 4 or more times. Thanks for the clarifications, that explains it. > > Thanks for the code. Questions 1: > > What exactly are we solving here? Forgive my ignorance, > > but for the whole lifespan of Harbour I've never needed > > anything like this, maybe because I've always used > > -n + MAIN() (and -n1 in libs). > > Question 2: Could we find a solution which doesn't > > need such hacks? > > The above is the only one really working solution to replicate > Clipper behavior and using as startup symbol 1-st linked function. > Such functionality can be implemented correctly only by linker. > Here we are trying to make it but because hbmk is not real linker > then it's implemented in such hackish way. > Of course we can define MAIN() as official startup symbol and remove > HB_FS_FIRST support from Windows compiler but it also has some bad > side effect. I know few programmers which never use -n switch and > have source code like: proc1.prg > ? "hello" > > proc2.prg > ... > > and create different binaries from them choosing different 1-st > .prg module. Okay. I still can't fully see the picture here. (see my question in answers 'part 1'. > > I'm a bit lost here. In autumn we've discussed once > > some possibilities for improvement here, to remove > > the -n1 switches, I guess you talk about the same. > > Then we've agreed on moving in on direction. > > 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? 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. > I do not see any problem here. If I do not use any compiler functions > then this library will be ignored at link time. > I think that it will be also good to add few contrib libraries like > hbct or hbmzip to default library list though it's not strictly necessary. I'd rather not hard-wire contribs into hbmk to keep dependencies and territories clear. Plus, we also have the .hbp config files in place. Including hbct (or hbmzip) takes this: - hbmk <my.prg> -lhbct .hbp gets useful when contrib needs some external libs, so you can simply say: - hbmk <my.prg> examples\xhgtk.hbp which will pick everything needed for xhgtk.hbp. That's the idea at least I couldn't yet test it specifically for xhgtk. We can also have a .hbp to setup all our popular and portable contribs, I'll create such .hbp: - hbmk <my.prg> contrib.hpb Brgds, Viktor
_______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
