On Tue, 1 Sep 2009, Przemyslaw Czerpak wrote: hi,
> > it seems as if INSTALL_RULE was assembled more than once, once with > > INSTALL_FILES set to libsddpg.a, but at the next iteration > > INSTALL_FILES was empty. afaict this second iteration must somehow be > > happening inside instsh.mk, as it is protected to be evaluated with an > > empty install_files list. > > Yes, it's a known problem caused by hack used to install header files > with libraries or binaries, i.e.: thanks, i got further with this. now it's external/libhpdf: make[3]: `../../../../../lib/sunos/sunpro/libhbxbp.a' is up to date. ! Installing xbp.ch on /tmp/hb/include ! Installing xbpdev.ch on /tmp/hb/include ! Installing appevent.ch on /tmp/hb/include ! Installing gra.ch on /tmp/hb/include ! Installing ../../lib/sunos/sunpro/libhbxbp.a on /tmp/hb/lib make[3]: `../../../../../lib/sunos/sunpro/liblibhpdf.a' is up to date. /bin/sh: syntax error at line 1: `;' unexpected make[2]: *** [install] Error 2 make[1]: *** [libhpdf.inst] Error 2 make: *** [external.inst] Error 2 this actually has been bugging me for a while - it seems that much (all, perhaps) other extensions are installed so that in lib<foo>.a there's both the glue code object to the original library (or the object implementing the complete functionality) and the harbour bridge. in case of hpdf, what gets installed is a libhbpdf.a (which is the hb bridge), and a liblibhpdf.a (which is libharu itself). is that supposed to be so? even if so, "liblib" seems somewhat unintentional.. thanks, -- [-] mkdir /nonexistent _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
