On Mon, 11 Feb 2008, Marek Paliwoda wrote: > >There are some techincal differences. > >1. On some system it will be hard (or impossible) to overload some > > subsystem using only libraries. F.e. nulrdd which should replaces > > whole RDD tree for applications which do not want to use any > > RDD releated code will not work if you will try to link sth like: > > gcc myapp.o -lnulrdd -lhrb > > because myapp.o has no reference to any symbols in nulrdd so > > nulrdd will be ignored and then all RDD code will be taken > > from hrb where such references will appear. > > Of course such situatios exist only in few linkers. > Are you absolutly sure ? AFAIK there is *always* a reference to RDD > code from VM. Otehrwise it would be possible to link an executable > without *any* rdd library, which is IMO impossible. So yes, > gcc myapp.o -lnulrdd -lhrb > will work.
Yes, such reference exists. But VM code will be inside hrb and LD on some platforms when it will find it will take necessary code also from hrb because it does not check libraries parsed before. It's the reason why we are using -Wl,--start-group / -Wl,--end-group to resolve cross references problems in our code. But myapp.o will not have any references to RDD code so nulrdd will be ignored. > >2. Even if linker does not work like above then it will be hard > > to detect if libraries like nulrdd supports all necessary symbols. > > Even if sth will be missing then it be taken from hrb library > > so nulrdd will not functional as it should. > This will be a problem *only* for nulrdd. And I doubt it is used > by many users - if *any*. And it can easily testable, if we leave > old sepatare libraries buildable by for example setting an envvar > before a make process. So to me it's an example of "nonexistence" > problem. This problem will exist with any library if you will want to overload them. The solution is converting nulrdd and other libraries to object files (*.o). In such case LD will always link them though sometimes it also may not be expected behavior. Anyhow I agree that we can live with such limitation. But I really suggest to create multi platform compiler and linker wrappers to hide such differences. Viktor said that HBMAKE should be sth like that but the biggest problem with HBMAKE is that it's a make application without many functionalities offered by real make systems so many users will not want to use it. ARAIR it also does not offer easy to use command line interface so application can be compiled and linked without make file at all and its make files are compiler and platform dependent. best regards, Przemek _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
