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
