On Thu, 27 Aug 2009, Viktor Szakáts wrote: > > > > using gcc 4.3.3, it too builds, in both c and cpp modes. > > > > > > > > granted, this is not core (yet), but maybe there's a way around this > > > > (maybe in a similar way as external/libhpdf/ explicitly switches to > > > > c mode). > > > > > > Is this a new error after latest changes? > > > > don't know, haven't built on linux (where there's qt) in a while. i'll > > check out an older version to see, any particular recommendations > > (before revision this-and-that)? > > Perhaps r12086 (2009-08-12 14:36) would be interesting to check.
nope, doesn't work. also tried r12087 (an arbitrary revision), no joy there either. fails at the same place (ie. very first qt source file). > > > Or we can just plain pass the list of objects. On most *nixes this > > > should not be a problem. > > > > i'd still vote for this, though. no particular reason, just gives me a > > warmer fuzzier feeling. whatever. just don't break not even gcc2, > > please ;) > > Would have preferred to do this, but I have no information > on *nix cmdline size limits. Currently we'd need 30-32K, > and may go up to 40K on the mid run. ouch. > Found this: > http://www.in-ulm.de/~mascheck/various/argmax/ based on this, if you do not want to deviate the various gcc.mks from each other much, please stick with the tempfile method for the time being. if you prefer separating by platform, whatever suits you. > To solve this we can jump into detecting *nix (Linux?) ISA > to the extent we have enough information to decide on this. > If this information is there, it's easy to solve. But may > this isn't such easy. > > The existing hbmk[2] logic here is to simply check for presence > of 64-bit dir and add it before regular dir if exist. Even lazier > solution is to always add the 64-bit dir, which I guess will be > ignored anyway by linker, if not there. For some reason though > this hasn't been done this way. > > Choice is up to *nix gurus. I'd go for the simplest which > works w/o side-effects. this (just prepending lib64) probably works fine. i don't know any other system besides redhat to work like this, anyway. we should probably wait for przemek to chime in, though, just to err on the safe side. > > uh. i don't see anything special in my env or anything, it's just so: > > Not wanted to imply that. you should have. although not in this particular case, these small things noone thinks of are oftentimes the problem. especially with me on the other side ;) > > this on ubuntu 9.04 x64, with no configuration out of the ordinary, as > > far as i can tell, and also on centos 4.8, with definitely no > > configuration out of the ordinary (very fresh install, and i don't > > know red hat enough to screw it up anyway :). > > x64 is the key. The one I have is x86 only. oki, so i'll run x86 builds too, every now and then. > I tried to emulate -fPIC usage on windows after your mail, but there > there wasn't a problem, I'll recheck on Ubuntu ASAP. and one of these commits fixed it too. thanks! -- [-] mkdir /nonexistent _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
