Basic linking question - VxWorks

This is a discussion on Basic linking question - VxWorks ; Hi, I have a lib file and a set of object files. Where can I find the documentation on how to build an executable module to be uploaded on the VxWorks target from the command line. Thanks, Manu...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Basic linking question

  1. Basic linking question

    Hi,

    I have a lib file and a set of object files. Where can I find the
    documentation on how to build an executable module to be uploaded on the
    VxWorks target from the command line.

    Thanks,
    Manu



  2. Re: Basic linking question

    "Emmanuel Stapf [ES]" wrote:

    >Hi,


    Hey now!

    >I have a lib file and a set of object files. Where can I find the
    >documentation on how to build an executable module to be uploaded on the
    >VxWorks target from the command line.


    An easy way is to execute make using makefiles generated by Tornado. If
    you insist on starting from scratch, the documents you seek are the tools
    manuals that are provided with your distribution, both on paper and in
    HTML files on your host. Most users use Wind River's version of the GNU
    tools for your target(s), but you may have purchased others, too.

    BTW, loading in the host to target direction is typically called
    downloading.

    >Thanks,


    HTH

    >Manu


    --
    ================================================== ======================
    Michael Kesti | "And like, one and one don't make
    | two, one and one make one."
    mrkesti at comcast dot net | - The Who, Bargain

  3. Re: Basic linking question

    > An easy way is to execute make using makefiles generated by Tornado. If
    > you insist on starting from scratch, the documents you seek are the tools
    > manuals that are provided with your distribution, both on paper and in
    > HTML files on your host. Most users use Wind River's version of the GNU
    > tools for your target(s), but you may have purchased others, too.


    Usually to link I do:

    ccppc -o
    sample -O3 -ansi -fno-builtin -mlongcall -mstrict-align -DVXWORKS -IC:/Tornado2.2/target/h
    object1.o object2.o libmylib.a

    But when I do that I get:

    c:/Tornado2.2/host/x86-win32/bin/../lib/gcc-lib/powerpc-wrs-vxworks/gcc-2.96/../../../../powerpc-wrs-vxworks/bin/ld:
    cannot open libgcc.a: No such file or directory
    collect2: ld returned 1 exit status


    I've looked at the commands issued by the Tornado but I must admit I'm not
    sure to understand what they mean. Here is a sample output when building a
    project from Tornado:

    <<
    vxrm *.o *.rpo ctdt.c symTbl.c vxApp* *.out *.pl
    vxrm ..\prjComps.h ..\prjParams.h ..\prjConfig.c ..\linkSyms.c
    vxrm ..\libs.nm ..\libs.size
    ccppc -g -mcpu=604 -mstrict-align -mlongcall -ansi -fno-builtin -I. -IC:\Tornado2.2\target\h\
    -DCPU=PPC604 -DTOOL_FAMILY=gnu -DTOOL=gnu -c ..\helloworld.c
    vxrm ..\prjObjs.lst

    Generating ..\prjObjs.lst...
    ccppc -r -nostdlib -Wl,-X -Wl,@..\prjObjs.lst -o partialImage.o
    nmppc partialImage.o @..\prjObjs.lst | wtxtcl
    C:\Tornado2.2\host\src\hutils\munch.tcl -c ppc > ctdt.c

    ccppc -c -fdollars-in-identifiers -g -mcpu=604 -mstrict-align -mlongcall -fno-builtin
    -I. -IC:\Tornado2.2\target\h\ -DCPU=PPC604 -DTOOL_FAMILY=gnu -DTOOL=gnu
    ctdt.c -o ctdt.o

    ccppc -r -nostdlib -Wl,-X -T
    C:\Tornado2.2\target\h\tool\gnu\ldscripts\link.OUT partialImage.o ctdt.o -o
    Test.out
    >>


    So my question is the following, what is the meaning of the second part with
    `prjObjs.lst', `partialImage' and `ctdt'. Is this really necessary to link?
    Any other quicker way to achieve this?

    Thanks,
    Manu



  4. Re: Basic linking question

    Emmanuel Stapf [ES] wrote:

    .... stuff deleted

    > I've looked at the commands issued by the Tornado but I must admit I'm not
    > sure to understand what they mean. Here is a sample output when building a
    > project from Tornado:
    >
    > vxrm *.o *.rpo ctdt.c symTbl.c vxApp* *.out *.pl
    > vxrm ..\prjComps.h ..\prjParams.h ..\prjConfig.c ..\linkSyms.c
    > vxrm ..\libs.nm ..\libs.size

    1) Clean up the build directories.

    > ccppc -g -mcpu=604 -mstrict-align -mlongcall -ansi -fno-builtin -I. -IC:\Tornado2.2\target\h\
    > -DCPU=PPC604 -DTOOL_FAMILY=gnu -DTOOL=gnu -c ..\helloworld.c


    2) Build your application into an object file.

    > vxrm ..\prjObjs.lst
    >
    > Generating ..\prjObjs.lst...


    3) Add your application object file (helloworld.o) to the list.

    > ccppc -r -nostdlib -Wl,-X -Wl,@..\prjObjs.lst -o partialImage.o


    4) Create a partial link of just your application.

    > nmppc partialImage.o @..\prjObjs.lst | wtxtcl
    > C:\Tornado2.2\host\src\hutils\munch.tcl -c ppc > ctdt.c


    5) Create a file with arrays of C++ constructor and destructor function

    pointers, so that static global C++ objects are built and destructed.

    > ccppc -c -fdollars-in-identifiers -g -mcpu=604 -mstrict-align -mlongcall -fno-builtin
    > -I. -IC:\Tornado2.2\target\h\ -DCPU=PPC604 -DTOOL_FAMILY=gnu -DTOOL=gnu
    > ctdt.c -o ctdt.o


    6) Compile the constructors/destructors arrays.

    > ccppc -r -nostdlib -Wl,-X -T
    > C:\Tornado2.2\target\h\tool\gnu\ldscripts\link.OUT partialImage.o ctdt.o -o
    > Test.out


    7) Link the ctdt arrays with the application.

    > So my question is the following, what is the meaning of the second part with
    > `prjObjs.lst', `partialImage' and `ctdt'. Is this really necessary to link?

    Yes, if you have any C++ static global objects.

    > Any other quicker way to achieve this?


    Not really. You have to do step 7, because it not only links in the
    ctdt.o file, but also does the final link of your application.

    All Wind River Tornado 2.2 users that I know just run all the steps,
    even when they know that the ctdt.o file is essentially empty. It
    doesn't cost enough time to worry about.


+ Reply to Thread