Hi Viktor,
Next notes to current hbmk2:
1. gtcrs and gtsln are not in the list of linked libraries, gtxwc is
but see below.
hbmk should have list of all core libraries and verify which ones
exist in the lib dir.
2. hbmk2 does not add GT releated system libraries for static builds
if -gt<name> switch is not used. It means that
REQUEST HB_GT_<name>
in source code does not work.
For shared builds it should not be necessary for current SVN.
3. The logic for link time settings (GTs, fmstat, main func) is enabled also
for -hbcmp and -hbcc what breaks these options. Try to make:
hbmk2 -hbcmp t.prg
with GCC.
4. /usr/lib/harbour/libharbour.so is still passed explicitly with the path
to linked library list and hardcoded in final binaries. IMHO it should
never happen. I think about the logic of detecting system library list
but even if I implement it then hbmk2 will still create problems.
Just simply such binaries cannot be used on other computers. In most
of cases I have different local Harbour builds for production environment
and I need distributable binaries as result of compilation not local only
toys ;-) For local usage I can set any environment I want so I do not find
it as a problem but I cannot say the same about destination computers.
If you think it's usable for some reasons then please add new switch
like -fullpath or -share[path] which will store paths to shared libraries
in final binaries. But in such case please remember that you should not
pass <path>/libharbour.{so,sl,dyn,dll,...} to GCC parameters when -c
which is used in -hbcc or -hbcmp. In such form (not passed as -lharbour)
it's only link time GCC parameter and should not be used to compile
time phase.
best regards,
Przemek
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
