-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
i checked out 328 from the svn source and now I get this when trying to build.
make[2]: Leaving directory `/home/matt/op25/blocks/src/lib' Making check in python make[2]: Entering directory `/home/matt/op25/blocks/src/python' make check-TESTS make[3]: Entering directory `/home/matt/op25/blocks/src/python' Traceback (most recent call last): File "./qa_op25.py", line 24, in <module> import op25 File "/home/matt/op25/blocks/src/lib/op25.py", line 24, in <module> _op25 = swig_import_helper() File "/home/matt/op25/blocks/src/lib/op25.py", line 16, in swig_import_helper import _op25 ImportError: /home/matt/op25/blocks/src/lib/.libs/_op25.so: undefined symbol: _ZNK4ldu23lcfEv FAIL: run_tests ================== 1 of 1 test failed ================== make[3]: *** [check-TESTS] Error 1 make[3]: Leaving directory `/home/matt/op25/blocks/src/python' make[2]: *** [check-am] Error 2 make[2]: Leaving directory `/home/matt/op25/blocks/src/python' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/home/matt/op25/blocks/src' make: *** [check-recursive] Error 1 matt@matt-Inspiron-1525:~/op25/blocks$
I cant shake it; any help will be much appreciated.
- -- - ------ Matt D - ------------
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I'm sorry I don't understand. what can i do to get the make test to pass?
On 12/10/2013 04:32 PM, Steve Glass wrote:
The target you are looking for is "make check".
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
right make check is what i meant. that "1 test failed" comes from doing the make check.
On 12/10/2013 04:46 PM, Matt D wrote:
I'm sorry I don't understand. what can i do to get the make test to pass?
On 12/10/2013 04:32 PM, Steve Glass wrote:
The target you are looking for is "make check".
Matt
Are you getting this error on a standard build of op25, or does this contain local mods?
The linker error about undefined symbol ....ldu2... is the root error which needs to be addressed
Somewhere in the code there is a reference to this symbol (as printed in the error message it's mangled as a C++ var name) - you may need to do some detective work to isolate the cause of the undefined symbol
Max
You are referring to a function in the source code which is not linked into the binary. Specifically:
echo _ZNK4ldu23lcfEv | c++filt ldu2::lcf() const
Which is the function I presume you've written. For whatever reason the code for that function is not present in the object files the linker knows about. Hope that helps.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
thanks a bunch, i have to sharpen my eyes when reading that sort of message. it started when I uncommented some code i put in ldu1.cc, ldu1.h, ldu2.c and ldu2.h; so I knew that had something to do with it. What can be done with this sort issue?
On 12/10/2013 07:17 PM, Steve Glass wrote:
You are referring to a function in the source code which is not linked into the binary. Specifically:
echo _ZNK4ldu23lcfEv | c++filt ldu2::lcf() const
Which is the function I presume you've written. For whatever reason the code for that function is not present in the object files the linker knows about. Hope that helps.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
The seg fault from trying to use extract remains:
Program terminated with signal 11, Segmentation fault. #0 extract<std::vector<bool, std::allocator<bool> > > (in=..., bits=bits@entry=0xa3309ce0, bits_sz=bits_sz@entry=8) at ./op25_yank.h:109 109 x = (x << 1) | (in[bits[i]] ? 1 : 0); (gdb) bt #0 extract<std::vector<bool, std::allocator<bool> > > (in=..., bits=bits@entry=0xa3309ce0, bits_sz=bits_sz@entry=8) at ./op25_yank.h:109 #1 0xb2e0aa53 in ldu1::lcf (this=0xb498148) at ldu1.cc:138 #2 0xb2e08931 in ldu1::snapshot (this=0xb498148) at ldu1.cc:102 #3 0xb2e0f42b in snapshot_du_handler::handle (this=0xadc8b28, du=...) at snapshot_du_handler.cc:44
I can not figure out what I am doing wrong. I tried to copy how it this procedure is done in abstract_data_unit::frame_body(). I give the vector to extract() like this:
uint16_t ldu1::lcf() const { const size_t LCF_BITS[] = { 0, 1, 2, 3, 4, 5, 6 , 7 }; const size_t LCF_BITS_SZ = sizeof(LCF_BITS) / sizeof(LCF_BITS[0]); const uint16_t lcf = extract(get_vec(), LCF_BITS, LCF_BITS_SZ); return lcf;
}
const_bit_vector& ldu1::get_vec() const { return decoded_lcw_vec; }
and i know the vector is there becuase it prints to the screen before the program dies:
DU1 LCW Data-------------------------------------------- - ----------------------------------------------------------- Encoded LCW: LCF: 00000000 MFID: 00000000 TGID: 0000000000000001 Source ID: 001000100000011111111101
Hamming decode: LCF: 00000000 MFID: 00000000 TGID: 0000000000000001 Source ID: 001000100000011111111101
RS decode: LCF: 00000000 MFID: 00000000 TGID: 0000000000000001 Source ID: 001000100000011111111101
Decode LDU1 LCW Vector Complete:000000000000000001000000000000000000000000000001001000100000011111111101 - -----------------------------------------------------------
the vector is defined private in the .h file. Any help will be much appreciated.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
the vector is defined private in the .h file. Any help will be much appreciated.
something has got to be wrong with the vector, or how I am trying to get it into the other functions, although I do not know what. Trying to print the vector in another makes the program die exactly at the time of trying to access the vector:
Program terminated with signal 11, Segmentation fault. #0 operator bool (this=<optimized out>) at /usr/include/c++/4.7/bits/stl_bvector.h:82 82 { return !!(*_M_p & _M_mask); } (gdb) bt #0 operator bool (this=<optimized out>) at /usr/include/c++/4.7/bits/stl_bvector.h:82 #1 operator* (this=<optimized out>) at /usr/include/c++/4.7/bits/stl_bvector.h:288 #2 operator[] (__n=0, this=<optimized out>) at /usr/include/c++/4.7/bits/stl_bvector.h:712 #3 ldu1::lcf (this=0xaf702010) at ldu1.cc:137 //print statement location #4 0xb2d4ea01 in ldu1::snapshot (this=0xaf702010) at ldu1.cc:102 #5 0xb2d539ab in snapshot_du_handler::handle (this=0xa8ffcf0, du=...) at snapshot_du_handler.cc:44 #6 0xaf703aa4 in ?? ()
here is the function where the print is located: uint16_t ldu1::lcf() const { int i; uint16_t lcf; printf("\n LCF: "); for(i=0; i<8; i++) cout << decoded_lcw_vec[i]; for(i=0; i<8; i++) lcf = decoded_lcw_vec[i]; return lcf;
}
Some say vector<bool> is buggy and cannot be trusted but I see it works well in the rest of the program. How can I safely get the vector from one function to another without putting it in as a function parameter?
The code snippets help but you need to let us see all of it. Post the ldu1.cc and ldu1.h files.
There is nothing wrong with std::vector<bool> - it is a basic STL class and works reliably when used correctly. I think you've got a lifecycle problem and are accessing an object reference after the referenced object has been destructed. There are simple tests you can do to verify that in the debugger but, for now, post all the code in case we can see something obvious.
The way these classes work is that each represents a frame. We do error correction for the whole frame at one time and then extract just the data bits we need in the accessors. So storing the "decoded LCF" is not how we go about it. Instead, decode and apply the error correction to the frame content and then let the accessor get just the codeword bits.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Alright so here is the files and the traffic pane to display and log the data. Currently as far as I can tell it is working well. The only thing I could not do is figure out how to use the typedef bit_vector so instead I use an array declared private to hold the error corrected LCW.
On 12/11/2013 06:26 PM, Steve Glass wrote:
The code snippets help but you need to let us see all of it. Post the ldu1.cc and ldu1.h files.
There is nothing wrong with std::vector<bool> - it is a basic STL class and works reliably when used correctly. I think you've got a lifecycle problem and are accessing an object reference after the referenced object has been destructed. There are simple tests you can do to verify that in the debugger but, for now, post all the code in case we can see something obvious.
The way these classes work is that each represents a frame. We do error correction for the whole frame at one time and then extract just the data bits we need in the accessors. So storing the "decoded LCF" is not how we go about it. Instead, decode and apply the error correction to the frame content and then let the accessor get just the codeword bits.