On 21/07/2011 21:36, Dondo, Brian wrote:
> Hi.  (am I supposed to say hi on mailing lists?)

You can say hi if you want ;)

> Building 6.1.3 and 5.0.14 VSO on Ubuntu 9.10 and 10.04.  Builds on 32 bit 
> Ubuntu presents no problems with either release of VSO.
> 
> It's worth mentioning right away I'm using the -with-iodbc=DIR option.  (=DIR 
> because for some reason in 10.04 the make isn't able to figure the absolute 
> path when it needs it)

That's ok, as long as you have libiodbc2-dev installed on all platforms
involved.

> However, we're planning on going live using 64-bit compilations on 64-bit 
> servers.  The other combinations were done because I'm stuck working the 
> angles on this.
> 
> The targeted combination is 5.0.14 VSO on 10.04 Ubuntu 64-bit.  This is where 
> it gets weird.  I can make and make check 5.0.14 on Ubuntu 9.10 64-bit with 
> no problems BUT on 10.04 it compiles clean but I can't run a successful make 
> check.  There're a couple flashes of errors near the beginning of the check 
> and then things go well until it eventually grinds to a halt(ish) when 
> "Running a subset of TPC-D queries against 1111"
> 
> And this is where it gets weirder still.  If I run the make on 10.04 64-bit, 
> tarball the make directory over to a 9.10 64-bit OS and run the make check 
> there, it runs clean!
> 
> Is there a quirk in Ubuntu that could be causing this?  Is it the test suite 
> on 10.04?  The 10.04 compile tests clean on 9.10. Can I trust the binaries on 
> 10.04 if I package them up and install them using Debian utilities?

It's certainly possible there might be quirks; could be that you have older
versions of required packages[0]; could be locale settings[1] at fault
(gawk has been known to be problematic on utf-8 locates before now).

[0] Please double-check against
<http://virtuoso.openlinksw.com/dataspace/dav/wiki/Main/VOSMake#Package%20Dependencies>

[1] Please check the output of `locale` on all environments

Best bet is if you send us the various tsuite log files, mostly
binsrc/tests/suite/testall*{output,log} so we can look for more precise errors.

HTH,

~Tim
-- 
Tim Haynes
Product Development Consultant
OpenLink Software
<http://www.openlinksw.com/>
<http://twitter.com/openlink>

Reply via email to