On Fri, 27 Feb 2009, Szak�ts Viktor wrote:
Hi,
> > 4. automatic 1-st funtion detection does not work:
> > echo "proc p;? 'hello'" > t.prg && hbmk2 -n -q2 t.prg && ./t
> > Unrecoverable error 9012: Can't locate the starting procedure: 'MAIN'
> I disabled it, because it needs multiple passes to C compiler,
> I'd like to find some better solution to this. Also, the -n issue
> is already a FAQ, so we should IMO find some solution for the
> various startup proc problems as a whole (also -n1). Current
> situation is rather confusing and also platform dependent.
For GCC when hbmk2 compiles .prg code then it does not need any additional
C compiler call. It's enough to check generated by Harbour .c code and
generate additional .c file which you can add to already executed gcc
command. The same is also rue for other .c control files. They does not
have to be compiled separately when GCC is used. Just simply add them to
link command. Other C compilers may work in different way here.
The problem with -n1 is still open. But if hbmk2 does not give automatic
alternative then it's hard to remove it from compiler.
In the weekend I'll check if I can easy add some type of starting procedure
auto detection to harbour compiler. It will check if the 1-st automatic
procedure has any executable code. If yes then it will be added. If not
then all declarations will be file wide.
It may reduce the problem at least for users which tries to compiler
different examples forgetting about -n switch. But if for such extensions
it's necessary to introduce some more complicated hacks then I'll leave it
to some deeper compiler modifications.
Anyhow without some support from hbmk2 it's not possible to detect what
is the 1-st procedure at runtime. When hbmk2 is used with .prg files then
it's enough to add new harbour compiler switch but when it's used to
link object files it will not be enough.
> > 5. it still creates binaries which uses harbour static libraries in *nixes
> Did you install it? It will only create shared if installed to a system
> location (where .so is expected to be available without burnt in
> .so dirs that is). See my longer post to your previous mail about some
> more refinement we can make here (like LD_PATH check for harbour*.so
> example). You can also force it by adding line 'shareddef=yes' to hbmk.cfg.
> hbmk.cfg will be picked from these locations: ~/.harbour, /etc/harbour,
> bin/../etc/harbour, bin/../etc, bin. In that order.
I have system wide installation but probably hbmk2 was confused by
links I used. I've just emulated default system installation and
shared library is created but full path to harbour shared library
is hardcoded into final binaries:
druzus:/tmp/13# ldd t
linux-gate.so.1 => (0xffffe000)
/usr/lib/harbour/libharbour.so (0xb7d9a000)
It should be fixed. All such things will very badly interact with
customized installation or system settings, f.e. when user have
to use dchroot.
Automatic checking for system library directories may not be such
easy as simple LD_PATH or other envvar checking but I'll look for
some method which will work in Linux,.
> > 6. -fullstatic does not work. When this switch is used -static parameter
> > should be passed to gcc. You cannot test it in MinGW because here
> > such functionality does not exists and system libraries cannot be
> > included.
> I know. See my other post, I need your help, or more details instructions
> what to fix exactly. I have no idea what the option means, just tried to
> copy the logic from hbmk script. Pls use -trace and post the wrong and
> fixed command lines.
I've wrote it in above sentence. -static GCC link time parameter should
be added when -fullstatic hbmk2 option is used. That's all.
You can use 'ldd <appname> to check the final binaries status. For dynamic
binaries it will also show you all used libraries.
> > 7. The installation paths (LIB/INCLUDE) are not stripped:
> > hbmk2 -n -q2 -shared t -trace
> > hbmk: Harbour compiler command:
> > /home/druzus/CVS/harbour/out/bin/../bin/harbour t \
> > -i/home/druzus/CVS/harbour/out/bin/../include -n -q2
> > hbmk: C compiler command:
> > gcc t.c -O3 -ot -I/home/druzus/CVS/harbour/out/bin/../include \
> > -L/home/druzus/CVS/harbour/out/bin/../lib -L/usr/X11R6/lib \
> > -Wl,--start-group -lharbour -lhbcplr -lhbdebug -lm -ldl -lrt \
> > -lncurses -lslang -lX11 -Wl,--end-group
> It will only strip paths when installed on a system location.
> I can enable it for all cases, but it might be dangerous if
> links are used along the way. If you confirm this isn't a problem,
> I'll enable it. By "stripping" I meant to remove the '/../' parts
> of it, maybe you meant something else. Pls tell. :)
The native soft links should not be the source of any new problems here.
In theory it's possible that directory has entry ".." which does not
point to upper level dir. But for us it's unimportant. The ".." in the path
comes from hbmk2 not from the installation paths and hbmk2 assumes that ".."
points to upper level directory. It's not real path used during build/
installation process. If sth can be wrong (I do not expect such situation
in real life) then only because hbmk2 make it. If you think that striping
can be a problem then then simply create the path in different way.
Instead of:
cLibDir := cBinDir + "/../lib/harbour"
use:
cLibDir := dirname( cBinDir ) + "lib/harbour"
With such version you will exactly follow the paths used by build/installed
scripts.
Thank you very much for all you job on hbmk2.
best regards,
Przemek
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
