How to add libraries to iUniversal Project

The library that contains these symbols should be provided to the linker via the auto-generated linker.cmd file.  It should be something like codec_engine_<ver>/packages/ti/sdo/ce/ipc/dsplink/lib/release/...

If you don't see that in your generated linker.cmd file, your .cfg script is likely incomplete, and you may have more issues than just the library not being linked in.  Can you attach your .cfg script?

Chris

Chris

See attached file

Ofer1121.remote_ti_platforms_evm3530_cfg.txt

Indeed the IPC is not there - so I can I add this ? via cfg file?

Ofer

I want to say you should remove this line from your .cfg script:

osalGlobal.armDspLinkConfig = osalGlobal.DEFAULT_ARMDSPLINKCONFIG;

You _should_ be getting the necessary library (with the Comm_* symbols) by setting the osalGlobal.runtimeEnv (as you're doing), so I can't explain why the libs aren't there.  Maybe the config setting above (that I want you to remove) are somehow causing an issue?  Try removing that line and see if it helps.

Chris

Chris,

It did not help.

Ofer

Chris

Any other ideas?

Help...

Ofer

As Chris said, the lib containing Comm should be automatically included.

Do you get any errors/warnings during the XDC config phase of your build?

The XDC config phase should be generating a linker command file in <app_dir>/package/cfg/<binary_subdir_path_of_app_dir>/<app_name>_<app_extension>.xdl.  That .xdl file should have a line similar to the following:    /<codec_engine_dir>/ti/sdo/ce/ipc/dsplink/lib/release/ipc_syslink.av5T.

I assume you don't have the above line in your .xdl file, else you wouldn't be getting the undefined reference errors.  Perhaps the ipc/dsplink module didn't recognize your application suffix (extension, something like 'v5T').

Would you be able to attach your application's .xdl file?  (the auto-generated one mentioned above).

Regards,

- Rob

Rob

By the way the link.xdt file in the Codec directory is empty (?)1588.remote_ti_platforms_evm3530_xv5T_xdl.txt

I changed the name of the file so it can be attached

Ofer

Rob

also I did not get any warnings during XDC and how can I fix the "Perhaps the ipc/dsplink module didn't recognize your application suffix (extension, something like 'v5T')."? also maybe the following line are not correct

var MyEngine = Engine.createFromServer(

"factorialEngine",  // This name only present here so maybe this shall be set differently

...

)

Ofer

Ofer,

I'm starting to suspect that the release you're using has a problem.  Could you simply add this line to your .cfg file:?
    xdc.useModule('ti.sdo.ce.ipc.dsplink.Ipc");

I suspect this will do the trick for you.

I had already written some explanation/answers when I came up with the above suggestion, and it might help to read it, so enjoy...

Thanks for sending the generated .xdl linker command file.  Indeed, the <codec_engine>/packages/ti/sdo/ce/ipc/dsplink/lib/release/ipc_dsplink_3530.av5T is not in there, which is the first level of explanation for why those Comm_* references remain undefined.  The next level of explanation has to do with why that line is not present in your .xdl file.  BTW, it's normal for the link.xdt file in the example directory to be empty - it's a placeholder for potential user content, of which the examples need none.

The "application suffix" issue to which I referred isn't something you'd generally see, or be able to fix.  What you can see during the config phase, when it works correctly, is a line like the following, generated by the <codec_engine>/packages/ti/sdo/ce/ipc/dsplink/package.xs file:
    will link with ti.sdo.ce.ipc.dsplink:lib/release/ipc_dsplink_3530.av5T
When there is a problem with this, there is no error or any output, just the lack of the above "will link" line.  If there was a problem with your application suffix then you would not get the above line, however, I can see from your generated .xdl file that your extension (v5T) is indeed valid.

The only other way for the ipc/dsplink/package.xs file to fail to return you a valid lib (via its getLibs() method) is if your "device" name is not one that is recognized by that file.  It uses Program.cpu.deviceName to match the right library, and is looking for the 3530 it's looking for a name *ending* in OMAP3530.  If you can sanity-check this it would help rule out non-issues (or identify the issue directly).  Try this in your .cfg file to print your name:
   print("device name = " + Program.cpu.deviceName);
(you might need the full "xdc.cfg.Program.cpu.deviceName" if it doesn't recognize Program.cpu.deviceName).

Having said all the above, I'm starting to suspect that the release you're using has a problem.  Could you simply add this line to your .cfg file:?
    xdc.useModule('ti.sdo.ce.ipc.dsplink.Ipc");

Regards,

- Rob

Rob

it says that there is no module like that (I do see the ipc module). Now CE is the only tool (in compare to dsplink, XDC etc) that I think there was no installation presented (no bin file). Should ZI compile something ? maybe my CE "installation" is not correct

Ofer

Rob

I figured out that Ipc is with capital letter I, but now I received the same undefined reference....

Ofer

Also device name = OMAP3530

Ofer

Rob,

I installed new XDC tools release. Now I am getting ld: .gnu.attributes not found for insert

Ofer

I removed the SECTIONS from the linkcmd.xdt and the INSERTBEFORE .gnu.attributes and I am exactly where I was before the upgrade that is undefined reference

Ofer

Ofer,

So, once you corrected the capital 'I', I assume that the XDC config phase didn't report any error.

Can you attach a zip file of your complete project, generated files and all?

At this point I want to see the generated .xdl linker command file (the one down in the 'package' subdir), but I'm not sure what else might be of value, so including the whole project might prove useful.

Regards,

- Rob

3323.linkcmd_xdt.txtRob

I attach the complete package: The DSP directory is a placeholder for: (1) Apps - that includes the randgen that is not compiling. Note that my algorithem/codec is factorial as described in (2)  but I did not change the reused randgen application files structures and names except the neccessery commands1680.DSP.tar.gz.  (2) Cssn (my Codec - actually just a simple factorial procedure) (3) Server

Several comments:

[1] Yes after using the 'I' there is no XDC config phase issues - I am at the situation I am facing in which the Ipc library is not included.

[2] I upgraded the CodeSourcery and XDC tools releases (to be the latest)

[3] I delete SECTION {} in the packages/gnu/targets/arm/linkcmd.xdt or else I am receiving error ld 11

[4] I deleted INSERT BEFORE .gnu.attributes' command in the packages/gnu/targets/arm/linkcmd.xdt or else I am receiving an error

Thanks for your help

Ofer

Rob,

I think I have a direction other than the .runtimeEnv the .ipc also shall be set. I am checking this

Ofer

else it is using wrong dsplink lib (as I have in my INPUT section)

Rob,

When I am tring local (vs Remote) via ti,sdo.ce.ipc.linux.Ipc I do get the library (local) linked (I am getting other error of redefinition but at least the library is linked)

Help please.

Thanks Ofer

Ofer Zimmerman said:

[2] I upgraded the CodeSourcery and XDC tools releases (to be the latest)

It's probably not a good idea to upgrade XDC tools, since all the other packges expect things as they are in the XDC tooling with which they're built.  You should be using XDC 3.16.00.18.

Upgrading CodeSourcery is most likely fine.

Ofer Zimmerman said:

[3] I delete SECTION {} in the packages/gnu/targets/arm/linkcmd.xdt or else I am receiving error ld 11

[4] I deleted INSERT BEFORE .gnu.attributes' command in the packages/gnu/targets/arm/linkcmd.xdt or else I am receiving an error

These are probably because of your XDC upgrade being incompatible with other stuff.

FYI, and you probably know this but I'll just say it, it's not a good idea to modify installed package content.

I looked inside your project files.  Indeed it looks like your configuration is including ti.sdo.ce.ipc.dsplink since I can see reference to it in other generated files.  The big "sticker" here is that there is no reference to
        /home/ofer62/codec_engine_2_26_02_11/packages/ti/sdo/ce/ipc/dsplink/lib/release/ipc_dsplink_3530.av5T
in your linker.cmd as there should be.  Can you verify that this library even exists?

If that ipc_dsplink_3530.av5T file does exist, then the ti/sdo/ce/ipc/dsplink/package.xs file is not correctly returning the lib in its 'getLibs()' function.  Everything in your project seems like it is set correctly to get the appropriate lib returned, but this is the last sticking point that I can't resolve.  Would you be able to put some debug prints in that file (ti/sdo/ce/ipc/dsplink/package.xs)?  Copy-paste the following, replacing the existing getLibs() with this content, and report back with its output (you may need to 'touch' your .cfg in order for the config to run again):
/*
 *  ======== getLibs ========
 */
function getLibs(prog)
{
    var lib = "";
    var device = prog.cpu.deviceName;
    var isa = prog.build.target.isa;

    var suffix = prog.build.target.findSuffix(this);
    if (suffix == null) {
        print(this + ": findSuffix() returned null (deviceName=" + device + " isa=" + isa + ")");
        return ("");
    }

    /* device = DM6446, cpu = ARM */
    if (device.match(/^TMS320CDM6446$/) && isa.match(/^v5T$|^v6$|^v4T$/i)) {
        lib = "lib/" + this.profile + "/ipc_dsplink_6446";
    }

    /* device = DM357, cpu = ARM */
    else if (device.match(/^TMS320DM357$/) && isa.match(/^v5T$|^v6$/i)) {
        lib = "lib/" + this.profile + "/ipc_dsplink_357";
    }

    /* device = DM6467, cpu = ARM */
    else if (device.match(/^TMS320CDM6467$/) && isa.match(/^v5T$|^v6$/i)) {
        lib = "lib/" + this.profile + "/ipc_dsplink_6467";
    }

    /* device = OMAPL137, cpu = ARM */
    else if (device.match(/^OMAPL137$/) && isa.match(/^v5T$|^v6$/i)) {
        lib = "lib/" + this.profile + "/ipc_dsplink_137";
    }

    /* device = OMAPL138, cpu = ARM */
    else if (device.match(/^OMAPL138$/) && isa.match(/^v5T$|^v6$/i)) {
        lib = "lib/" + this.profile + "/ipc_dsplink_138";
    }

    /* device = TMS320C2430, OMAP2530, cpu = ARM */
    else if (device.match(/^TMS320C2430$|^OMAP2530$/) && isa.match(/^v5T$|^v6$/i)) {
        lib = "lib/" + this.profile + "/ipc_dsplink_2530";
    }

    /* device = TMS320C3430, OMAP3530, cpu = ARM */
    else if (device.match(/^TMS320C3430$|^OMAP3530$/) && isa.match(/^v5T$|^v6$|^v4T$/i)) {
        lib = "lib/" + this.profile + "/ipc_dsplink_3530";
    }

    /* empty lib means this package has nothing to contribute */
    if (lib != "") {

        /* .findSuffix found a compatible library */
        lib += ".a" + suffix;

        /* return the library name: name.a<arch> */
        print("    will link with " + this.$name + ":" + lib);
    }
    else {
        print("    couldn't find matching lib (lib == null)");
    }

    return (lib);
}

Regards,

- Rob

Robert,

The build log attached. the library DOES exsist. Same issues with new XDC were presented with previous XDC. What do you mean by changing installed package content? (I do not think I changed a package content).8461.BuildLog.txt

Ofer

This line from your build log points to the issue:
    ti.sdo.ce.ipc.dsplink: findSuffix() returned null (deviceName=OMAP3530 isa=v5T)
The ti/sdo/ce/ipc/dsplink/package.xs:getLibs() method is not able to match a suffix for your configuration, which explains why you are not getting its library specified in your linker.cmd file.  Now we need to figure out why, since it's clear from other generated content that other libraries are indeed found, also based on the findSuffix() internal method.

I enlisted an XDC developer to help with the next step.  He said that the only way he could see that this sort of error could happen was if the ti.sdo.ce.ipc.dsplink package was corrupted (or, if not corrupted, different than what it should be).  Did you attempt to rebuild Codec Engine (you probably didn't, just making sure)?

Would you be able to zip up your <codec_engine>/packages/ti/sdo/ce/ipc/dsplink/package subdirectory contents (recursively)?  The file build.cfg in the package subdir should contain a list of libraries in this package, and I need to see that.

Ofer Zimmerman said:

What do you mean by changing installed package content? (I do not think I changed a package content

I'm referring to this from you:

Ofer Zimmerman said:

[3] I delete SECTION {} in the packages/gnu/targets/arm/linkcmd.xdt or else I am receiving error ld 11

[4] I deleted INSERT BEFORE .gnu.attributes' command in the packages/gnu/targets/arm/linkcmd.xdt or else I am receiving an error

Those changes are changing an installed XDC package.

Regards,

- Rob

Robert,

I did not rebuild Codec Engine, but yes I think I run make in this library directory but only after I had issues regarding that library  (the one that is not received by getLibs()). regarding Codec Engine as I asked before all I did during installation is unzip the package, I did not see any install procedure.  Should I get that file again from the zip package? 

The change I did regarding SECTIONS was recommended by you or one of your collegues 2234.package.tar.gzwhile attempting to solve ld error 11 (I was told it is a code sourcery bug bypass and I followed TI's expert instructions).

The other fix regarding the INSERT is done by me or else there is error as i indicated.

Thanks Ofer

Ofer,

Ofer Zimmerman said:

but yes I think I run make in this library directory but only after I had issues regarding that library

This is probably the issue.  The package/build.cfg file that you sent is basically empty (i.e., it defines empty data structures).  Please try to get the CE installation file again and unzip it in the same place.

I'm suspecting that the package was fine before your 'make' and that your issue was a problem in CE 2.26, the one I mentioned before about needing to manually do:
    xdc.useModule('ti.sdo.ce.ipc.dsplink.Ipc');
So, please try with a fresh install of CE and with the above line in your .cfg file.

Regards,

- Rob

Robert

Is it OK to unzip only that subdirecytory (=package, the one the I sent you?)

Ofer

I would suggest that you unzip the whole of the ti/sdo/ce/ipc/dsplink subdirectory, not just the package subdir of that.

- Rob

Robert,

It works! - 

Several questions: the file .xv5T is the executable produced I guess - can I execute it as I am normally doing for a.out?

What shall I do with my SECTIONS and INSERT changes?

I would like to thank you about your great help and support . 

Ofer

Ofer,

That's great to hear, this was a tough one.  If you're so inclined, you could try taking out the manual
    xdc.useModule('ti.sdo.ce.ipc.dsplink.Ipc');
and see if it still builds OK, but at this point I suspect you just want to stick with what works.

Ofer Zimmerman said:

Several questions: the file .xv5T is the executable produced I guess - can I execute it as I am normally doing for a.out?

Yes, the .xv5T file should be invoked on your embedded Linux as an executable.

Ofer Zimmerman said:

What shall I do with my SECTIONS and INSERT changes?

Do you know the TI colleague that helped you before?  I don't know anything about those issues, so you could try asking the same person that helped before.

Ofer Zimmerman said:

I would like to thank you about your great help and support . 

You're welcome, this stuff is not easy so we must help customers out.

Regards,

- Rob

Robert

if I may I would like to ask 2 questions:

while executing my executable on the target I got:

[1] Failed to open /dev/cmem  

[2] can't open engine 

Ofer

Did you edit/run loadmodules.sh?

Regards,

- Rob

Robert,

No I did not - should I ?

Ofer