Re: [Opensvcdecoder-support] how to integrate the openSVC decoder into a c++ class?

[Brett S. <bre...@gm...>]

Sorry, I am still having trouble with this...

[summary: make in Libs/SVC/build works. The libraries are built and linked
against, producing the svc executable. Trying to compile from within omnet,
I get a "symbol undefined for i386" error... makes sense, but switching to
a 32 bit machine so that the libraries will have to be built as 32 bit, I
get an error "symbols undefined"... even though it is finding the library
files, and I know the symbols are defined in there since svc builds...]

I successfully built the libraries (I can't get the SDL library to work on
make... it is installed as a framework, but that doesn't seem to make it
available for the building of the svc library... but I just removed it
since I don't need to display, I just want to write a yuv file).

The svc executable is created by typing "make" in the SVC/build folder...

In my Omnet project I have set it up with the proper include folders, and
the library folders, and set it to link against the libraries (I know
finding the libraries is not the problem, because if I put an intentional
typo, it throws and error that it cannot find it, so it is finding
the library files).

This is the link error I get:

Undefined symbols for architecture i386:
>   "init_svc_vectors(SVC_VECTORS*)", referenced from:
>       DecoderOpenSVC::Decode(int, unsigned char**)in DecoderOpenSVC.o

I thought this means that my 64 bit machine is compiling 64 bit libraries,
which 32 bit omnet cannot use.  I tried putting the -m32 option in the
makefile, but could not get it to successfully build the libraries that way.


So I switched to working on an old 32 bit machine. The link error I get
there is:


Undefined symbols:
>   "init_svc_vectors(SVC_VECTORS*)", referenced from:
>       DecoderOpenSVC::Decode(int, unsigned char**)in DecoderOpenSVC.o

I know that the symbols must be defined in the libraries, since the svc
executable is created by the makefile... yet when I try to compile the same
code inside a class's method in omnet, I get these link errors... despite
the fact that it is finding the library files... So I am very confused.


If anyone can offer any help, it would be greatly appreciated.


Thank you,

Brett Slote



On Wed, Jan 4, 2012 at 2:44 PM, Brett Slote <bre...@gm...> wrote:

> Sorry, please disregard my message. I looked at the Makefile instead of
> the VS project and immediately saw it is supposed to be linking against
> libraries. I will try to figure out why the libraries aren't building on my
> machine. Sorry again for the dumb question.
>
>
> On Wed, Jan 4, 2012 at 2:35 PM, Brett Slote <bre...@gm...> wrote:
>
>> Hello,
>>
>> This is a very basic question, but I'm not sure how to proceed.
>>
>> I'm hoping to call the openSVC decoder from a c++ class in the omnet++
>> network simulator.  I have a class that calls the JSVM decoder, and I'm
>> hoping to do the same with openSVC... but I don't understand it.
>>
>> I looked at the SVC_decoder_v9 class project, and the main(..) function
>> seems straightforward enough, so I thought it would be fairly straight
>> forward.
>>
>> But when I copied the code from main(..) into a method in a c++ object in
>> omnet, and copied the forward declarations above it, it did not compile.
>>
>> For example, the init_svc_vectors(..) method on the first line of
>> main(..) is defined by a forward declaration above... and it seems to be
>> defined in MB_P_svc.c ... But MB_P_svc.h is not included anywhere, and even
>> if it was, it does not define the init_svc_vectors(..) method found in
>> MB_P_svc.c
>>
>> I have look all through the project settings to try to figure out how the
>> mainline is able to access this method (and all the others) without any
>> include, but I cannot find anything.
>>
>> I am only familiar with c++, and I am not used to seeing all these
>> methods without being contained in classes. But it seems that they should
>> still have to be included somewhere to work.
>>
>> If anyone could give me any clue as to what I am missing, I would
>> appreciate it.
>>
>> Thank you,
>>
>> Brett Slote
>>
>
>