On Wed, 04 Mar 2009, Szak�ts Viktor wrote:
Hi,
> I'd like to avoid the kind of parsing like that. Such information
> should be passed through hbmk.cfg if needed for hbmk2 workings.
> gtcrs and gtsln should also be picked up from hbmk.cfg.
But they aren't so please fix it.
I also do not understand this logic. So why GTXWC is in the linked
library list?
> Please provide some example I can do testing on, because
> it was very difficult to decipher the original logic of these, and
> it's possible that I didn't test some scenarios, or missed some
> things.
1-st the very basic functionality. We will talk about other features
when this part will be ready:
1. hbcmp -> create .o file from given .prg ones
2. hbcc -> C wrapper which set -I, -L paths and -l libraries.
3. hblnk -> C link time wrapper. It should respect link time hbmk2
parameters like -gt*, -main=*
Basic test.
echo "? 'hello'" > t.prg
harbour t.prg -o tc.c -I<hbincdir>
hbmk t # result t[.<exeext>]
hbcmp t # result t.<objext>
hblnk t.<objext> # result t[.<exeext>]
hbcc -c t.c # result t.<objext>
When it will work you can try to compile XHGTK.
Just simply create hbcmp and hbcc links to hbmk2 and check if it works.
> > 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.
> I'll try to check.
> Could you pass me an example?
/* t2.prg */
REQUEST HB_GT_CRS_DEFAULT
proc main()
? "Hello"
return
hbmk2 -n -w -es2 -static t2
> > 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.
> I'll fix this ASAP.
Thank you.
> > 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.
> Please provide some details of your environment and hbmk2 cmd-line
> + -trace result when this happens, there are numerous factors and without
> more information I cannot refine it.
I do not understand why you need all these information. Simple test:
druzus:/tmp/18# hbmk2 -n -w -es2 -trace t
hbmk: Processing configuration: /etc/harbour/hbmk.cfg
hbmk: Harbour compiler command:
/usr/bin/harbour -n2 t -i/usr/include/harbour -n -w -es2
Harbour 1.1.0dev (Rev. 10523)
Copyright (c) 1999-2009, http://www.harbour-project.org/
Compiling 't.prg'...
Lines 4, Functions/Procedures 1
Generating C source output to 't.c'... Done.
hbmk: C compiler command:
gcc t.c /tmp/hbmk_aisbmo.c -O3 -ot -I/usr/include/harbour
-L/usr/lib/harbour -L/usr/X11R6/lib -Wl,--start-group
/usr/lib/harbour/libharbour.so -lhbcplr -lhbdebug -lm -ldl -lrt -lncurses
-lslang -lX11 -Wl,--end-group
/usr/lib/harbour/libharbour.so is passed explicitly not as -lharbour.
Result: final binaries have the hardcoded path:
druzus:/tmp/18# ldd t
linux-gate.so.1 => (0xffffe000)
/usr/lib/harbour/libharbour.so (0xb7c65000)
libm.so.6 => /lib/libm.so.6 (0xb7c17000)
libdl.so.2 => /lib/libdl.so.2 (0xb7c13000)
librt.so.1 => /lib/librt.so.1 (0xb7c0a000)
libncurses.so.5 => /lib/libncurses.so.5 (0xb7bd3000)
libslang.so.2 => /usr/lib/libslang.so.2 (0xb7b04000)
libX11.so.6 => /usr/lib/libX11.so.6 (0xb79e2000)
libc.so.6 => /lib/libc.so.6 (0xb789f000)
/lib/ld-linux.so.2 (0xb80e0000)
libpthread.so.0 => /lib/libpthread.so.0 (0xb7887000)
libxcb-xlib.so.0 => /usr/lib/libxcb-xlib.so.0 (0xb7884000)
libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb786b000)
libXau.so.6 => /usr/lib/libXau.so.6 (0xb7866000)
See:
/usr/lib/harbour/libharbour.so (0xb7c65000)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
It means that this binaries will not work with any other libharbour.so
location so I cannot distribute them.
best regards,
Przemek
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
