Hi Przemek,
> > 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 Ops, you're right, couldn't tell why was this my conclusion at that time :) > 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 would be great. Another thing which would be great and it's probably doable, although I'm not sure what amount of work it is: We have #pragma NOSTARTPROC option, but it only changes HB_FS_FIRST behaviour, so it isn't a full replacement for -n. If it would be (or we had such other #pragma), it could be easy to put it in all .prgs which need it. Overriding or specifying startup procedure may also be specified similar way: #pragma STARTPROC=MYSTARTUPFUNC Finally it might also help if Harbour would only pick the first func/proc in the first passed .prg as FIRST. (it won't help on objects, but would anyhow be useful for many cases IMO.) Just ideas. > 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. That's right. But to make me see more clear, is it the sole problem of gcc, or are there also other compilers? > 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. Wasn't intentional. I was a bit lost in this area, so it would be great if you could post some more info on your environment and hbmk2 settings. > 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,. Sounds great. > > 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. Thanks, sorry I've missed it. I've committed a fix. After the fix I'm getting this strange message: /usr/bin/ld: cannot find -lgcc_s > > > 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. Okay I'll check, my normalizer does something very similar, so it seems safe. Many thanks for the information. > Thank you very much for all you job on hbmk2. You're welcome! Brgds, Viktor
_______________________________________________ Harbour mailing list [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
