Hi Przemek, I just have a look at runner.c as dynsym.c but I must admit ... I do not see at this time where we actually skip loading symbol already existing in exe... :-(
Could you just point me in the right direction ? Thanks, JF -----Message d'origine----- De : harbour-boun...@harbour-project.org [mailto:harbour-boun...@harbour-project.org] De la part de J. Lefebvre Envoyé : lundi 8 juin 2009 12:30 À : 'Harbour Project Main Developer List.' Objet : RE: [Harbour] HRB question ??? Possible bug ! Hi Przemek, Thanks for the clarification (as usual :-) ). I could live with the KEEP_GLOBAL problem at unload as it is the same problem with the old "Blinker" loader. We could add a protection deactivating hrb unload in case of using the GLOBAL option. I will have a look at runner.c Friendly, JF, -----Message d'origine----- De : harbour-boun...@harbour-project.org [mailto:harbour-boun...@harbour-project.org] De la part de Przemyslaw Czerpak Envoyé : lundi 8 juin 2009 12:04 À : Harbour Project Main Developer List. Objet : Re: [Harbour] HRB question ??? Possible bug ! On Sun, 07 Jun 2009, J. Lefebvre wrote: Hi, > I tried this sample, because I was thinking that loading a HRB file would > load dynamically the HRB symbol table, adding new function or REPLACING > function with same name in the exe !!! In fact it just add new function, > always using exe function when they also exist. It works in such way. Existing public functions are not overloaded. In the past we were taking about adding optional parameter to HB_HRBLOAD() which will controll thbis behavior, f.e.: HB_HRBLOAD( [<nOptions>, ] <cHrb> ) We have the folowing choices: HB_HRB_DEFAULT 0 // do not overwrite any functions, ignore // public HRB functions if functions with // the same names already exist in HVM HB_HRB_KEEP_LOCAL 1 // do not overwrite any functions // but keep local references, so // if module has public function FOO and // this function exists also in HVM // then the function in HRB is converted // to STATIC one HB_HRB_KEEP_GLOBAL 2 // overload all existing public functions It can be quite easy implemented though there is one problem with HB_HRB_KEEP_GLOBAL. After module unloading the previous function won't be restored. Implementing such functionality needs much deeper modification because it's necessary to keep function references chain which have to be cleanly updated on each unload operation and it's possible that function FOO was overloaded by HRB module A then B finally by C and user unloads module in different order B then C and A at the end. It means that we have to dynamically change visible functions and we need structures where all existing hidden function will be visible and can be cleanly unlinked when module is unloaded. best regards, Przemek _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
