I think I may have dodged a bullet here...using gcc with -Os allows it to successfully compile and link!!
On Wed, Aug 29, 2012 at 2:25 PM, Michael Beauregard <[email protected]> wrote: > I meant to say that if I compile with clang, I get a corrupt .a output > file, but using gcc I get the following error repeated about 17000 > times: > > {standard input}:2179821:branch out of range > {standard input}:2179783:branch out of range > {standard input}:2179780:branch out of range > ... > > > On Wed, Aug 29, 2012 at 2:20 PM, Michael Beauregard > <[email protected]> wrote: >> Yes, I've had roughly the same realization. I'm not sure why this >> worked before, but maybe it was because I was using the query and >> bundle classes and now I'm using the table class for queries. >> >> Compiling everything together is only a problem when targeting the ARM >> processor. I found this potentially relevant comment >> http://stackoverflow.com/a/5777909/516581. >> >> I ended up splitting bord.cpp around line 6666. >> >> On Wed, Aug 29, 2012 at 2:13 PM, K. John Wu <[email protected]> wrote: >>> Hi, Michael, >>> >>> This might be related to implicit instantiation of template functions. >>> When in the same translation unit, most compilers will automatically >>> instantiate versions of templated functions as needed. However, when >>> crossing .o files, explicit instantiation is necessary usually. >>> >>> If you are simply splitting the existing file by two, may be you can >>> simple tell me the line number you are doing the cutting.. I will do >>> some experiment to figure out what needs to be explicitly instantiated. >>> >>> John >>> >>> >>> On 8/29/12 1:49 PM, Michael Beauregard wrote: >>>> Funny you should mention this now as I'm fighting this issue as we >>>> speak. Previously splitting them was necessary and working when >>>> targeting the device and unnecessary and problematic when targeting >>>> the simulator. Suddenly I'm getting the same linker errors when >>>> targeting the device. So my situation is that it is now necessary and >>>> problematic to split them up for the device now :-( >>>> >>>> Specifically, all symbols defined in the second part of bord.cpp (I >>>> called it bord_part2.cpp for now) are all unresolved by the linker. >>>> >>>> I'll let you know if/when I figure out how to fix this. >>>> >>>> Michael >>>> >>>> On Wed, Aug 29, 2012 at 1:31 PM, K. John Wu <[email protected]> wrote: >>>>> Hi, Michael, >>>>> >>>>> I remember that you mentioned that you have to split some files into >>>>> small pieces, would mind send us the split version? We will check >>>>> them into SVN as split files. This would make it easier for you to >>>>> move to the later versions when you need to. >>>>> >>>>> John >>>>> >>>>> >>>>> On 8/29/12 12:04 PM, Michael Beauregard wrote: >>>>>> The strange thing is that the lower number is actually the correct >>>>>> one. I suspect that this will require some concrete data for you to >>>>>> understand what's happening. I'll see if I can get a simple dataset >>>>>> for you that demonstrates the issue. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Michael >>>>>> >>>>>> On Wed, Aug 29, 2012 at 11:41 AM, K. John Wu <[email protected]> wrote: >>>>>>> Hi, Michael, >>>>>>> >>>>>>> Glad to hear that you are making good progress. Regarding the >>>>>>> off-by-one issue, here are a couple guesses on what could be going on. >>>>>>> >>>>>>> - The column named 'something' might have NULL values and one of the >>>>>>> NULL values happen to be included in the result set. FastBit does not >>>>>>> return any NULL values. >>>>>>> >>>>>>> - The retrieval function might have a bug. I would appreciate a >>>>>>> sample data to track down this bug. >>>>>>> >>>>>>> Thanks. >>>>>>> >>>>>>> John >>>>>>> >>>>>>> >>>>>>> On 8/29/12 11:18 AM, Michael Beauregard wrote: >>>>>>>> Thanks to John, I'm making decent progress with integrating FastBit >>>>>>>> into an iPad application. It builds and executes on my iPad and has >>>>>>>> better size and speed metrics than sqlite. So far so good. >>>>>>>> >>>>>>>> During testing I noticed that a certain FastBit aggregation was off by >>>>>>>> one compared to my sqlite result. Digging into a little, I noticed >>>>>>>> something that appears odd to me, but could just be a misunderstanding >>>>>>>> on my part. >>>>>>>> >>>>>>>> I would expect the aggregation result of the following query: >>>>>>>> >>>>>>>> ibis -d tmp/data -q 'SELECT count(*) WHERE thing_to_count = 16298' >>>>>>>> >>>>>>>> to match the number of hits returned by this query: >>>>>>>> >>>>>>>> ibis -d tmp/data -q 'SELECT something WHERE thing_to_count = >>>>>>>> 16298' >>>>>>>> >>>>>>>> However, I see that the two are off by one. The first query returns an >>>>>>>> aggregated value of 1195 and the second returns 1194 hits. >>>>>>>> Interestingly, for some reason the following query: >>>>>>>> >>>>>>>> ibis -d tmp/data -q 'SELECT thing_to_count WHERE thing_to_count = >>>>>>>> 16298' >>>>>>>> >>>>>>>> returns 1195 hits. I would expect all three queries to indicate the >>>>>>>> same number of matching rows since the conditions are exactly the >>>>>>>> same. For what it's worth, my sqlite result is 1194 and I'd consider >>>>>>>> that to be correct for my data. >>>>>>>> >>>>>>>> Any ideas? >>>>>>>> >>>>>>>> Michael >>>>>>>> _______________________________________________ >>>>>>>> FastBit-users mailing list >>>>>>>> [email protected] >>>>>>>> https://hpcrdm.lbl.gov/cgi-bin/mailman/listinfo/fastbit-users >>>>>>>> _______________________________________________ FastBit-users mailing list [email protected] https://hpcrdm.lbl.gov/cgi-bin/mailman/listinfo/fastbit-users
