Przemyslaw Czerpak wrote :
On Sun, 10 Feb 2008, Szakáts Viktor wrote:
I disagree. Having them as separate libraries has no advantages.
I just made some tests with GTs under BCC and including them in
link command changes *nothing*, until you *explicitly* REQUEST
a particular GT. So having them as separate libraries give us
nothing except complications in further link command, as oposed
to putting a *simple* REQUEST in prg source with one common lib.
I know it makes no _technical_ difference.
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.
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.
--
Marek
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
