Building sub-directories - VxWorks

This is a discussion on Building sub-directories - VxWorks ; Hi all, I've a doubt regarding the building system in vxworks. Presently we are building the entire vxworks library by giving a make on the Makefile in the vxworks-6.5 directory. It is building fine and we could link all the ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Building sub-directories

  1. Building sub-directories

    Hi all,

    I've a doubt regarding the building system in vxworks.

    Presently we are building the entire vxworks library by giving a make
    on the Makefile in the vxworks-6.5 directory. It is building fine and
    we could link all the sources to the archive file produced by this
    build.
    by giving the below mentioned make :
    make CPU=PPC603 CPU_VARIANT=_83xx TOOL=gnu FEATURE_SET=pcd comp-kernel
    ADDED_CFLAGS+=-g


    I've changed some routines in the vxworks source directory,WindRiver
    \vxworks-6.5\target\src\drv\end.

    So I need to build only this directory rather giving a make on the
    toplevel makefile in the vxworks-6.4 folder.

    I gave a build like this;
    make CPU=PPC603 CPU_VARIANT=_83xx TOOL=gnu FEATURE_SET=pcd ADDED_CFLAGS
    +=-g

    Please note that I've removed only the "comp-kernal" tag from the make
    command.
    But after giving the make ,my projects give a linking error from other
    libraries.

    I think the way to make from the sub-directories is not proper.

    Please give your ideas.

    Regards,
    Deepu


  2. Re: Building sub-directories

    On Aug 16, 5:48 am, Deepu wrote:
    > Hi all,
    >
    > I've a doubt regarding the building system in vxworks.
    >
    > Presently we are building the entire vxworks library by giving a make
    > on the Makefile in the vxworks-6.5 directory. It is building fine and
    > we could link all the sources to the archive file produced by this
    > build.
    > by giving the below mentioned make :
    > make CPU=PPC603 CPU_VARIANT=_83xx TOOL=gnu FEATURE_SET=pcd comp-kernel
    > ADDED_CFLAGS+=-g
    >
    > I've changed some routines in the vxworks source directory,WindRiver
    > \vxworks-6.5\target\src\drv\end.
    >
    > So I need to build only this directory rather giving a make on the
    > toplevel makefile in the vxworks-6.4 folder.
    >
    > I gave a build like this;
    > make CPU=PPC603 CPU_VARIANT=_83xx TOOL=gnu FEATURE_SET=pcd ADDED_CFLAGS
    > +=-g
    >
    > Please note that I've removed only the "comp-kernal" tag from the make
    > command.
    > But after giving the make ,my projects give a linking error from other
    > libraries.
    >
    > I think the way to make from the sub-directories is not proper.
    >
    > Please give your ideas.
    >
    > Regards,
    > Deepu



    First of all, it's "kernel," not "kernal."

    Second, you should be using the Diab compiler to build OS sources, not
    the GNU compiler. (Unless you cheaped out and didn't buy a Diab
    license.)

    Third, you're not supposed to use explicit CPU types when you build
    for PPC anymore (it used to be you had to specify the variant
    explicitly, but that was for VxWorks 5.5 and earlier: in 6.x, the
    rules have changed). There is one top level CPU type for all PPC
    processor types, called PPC32. When you build with CPU=PPC32 from
    target/src, it will build the objects for all of the CPU variants at
    once. You don't need to specify each one individually.

    Fourth, assuming you have the _entire_ OS source code installed (and
    you neglected to state explicitly whether you do or not), the right
    way to flush and rebuild all of the OS libraries is:

    % cd $(WIND_BASE)/target/src
    % make CPU=PPC32 TOOL=diab rclean
    % make CPU=PPC32 TOOL=diab FEATURE_SET=pcd ADDED_CFLAGS+=-g
    % make CPU=PPC32 TOOL=gnu FEATURE_SET=pcd ADDED_CFLAGS+=-g

    Yes, you must build once with Diab and one with GNU. The build with
    GNU only compiles the GNU intrinsics libraries (i.e. libgcc). Wind
    River only supports building the core OS with Diab nowdays. GNU is
    supported for customer apps and the objects are interchangable with
    Diab, but building of target/src is only tested with Diab (and there
    are a handful of files that won't compile with anything else). You
    only need to build with TOOL=gnu once in order to create the GNU
    intrinsics libraries. If you need to recompile code in a single
    subdirectory, you only need to do one compilation with TOOL=diab.

    NOTE: you must not do an rclean unless you have the full OS source
    available. An rclean will delete _all_ of the libraries under target/
    lib/ppc. If you don't have the source code to rebuild all of the
    libraries, you'll need to re-install to get them back.

    Once you've rebuild the whole OS, if you want to build in a single
    subdirectory, you can just do:

    % cd %(WIND_BASE)/target/src/drv/end
    % make CPU=PPC32 TOOL=diab FEATURE_SET=pcd ADDED_CFLAGS+=-g

    Now, as for why you're getting a link error, it's because you
    specified CPU=PPC603 when you tried to compile things before. If you
    look under $(WIND_BASE)/target/lib/ppc, you'll see two directories:
    PPC32 and PPC603. The PPC603 directory is _NOT_ supposed to be there.
    It was created because you didn't use the right CPU type, and it only
    contains partial libraries: instead of compiling new code and updating
    the libaries in target/lib/ppc/PPC32. you created new partially-
    populated libraries in target/lib/ppc/PPC603. The linker scripts
    happen to find the PPC603 directory first when you go to link your
    image, but since the libraries are incomplete, you now get unresolved
    symbol errors.

    To fix this, do the following:

    % cd %(WIND_BASE)/target/lib/ppc
    % /bin/rm -fr PPC603

    Now I know what you're going to ask: "But if I should only be using
    PPC32, why does part of the OS build use the CPU_VARIANT macro?" The
    only place where CPU_VARIANT matters is in target/src/arch or in this
    case, target/src/arch/ppc. There are some files in target/src/arch/ppc
    that need to be compiled differently for each PowerPC variant. For
    example, the cache and MMU implementation details vary a little bit
    between from one PowerPC processor type to another, so the same code
    won't work on all of them. Except for target/src/arch, all other OS
    code is variant-neutral and you only need to compile it once: the same
    object code will work on all PPC variants. (One exception to this is
    software floating point versus hardware floating point: for soft float
    builds, you must use sfgnu and sfdiab instead of gnu and diab.)

    -Bill


+ Reply to Thread