This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Problems with Building Lesson 5 of RTSC Tutorial

Guru 10685 points


I'm having trouble with the "xdc all" command in the RTSC tutorial on the eclipse website. It looks like a pretty simple example but the command fails and I'm not particularly sure why as all the other previous examples in lessons 1-4 have built fine. This is the webpage with the lesson in:

http://rtsc.eclipse.org/docs-tip/RTSC_Module_Primer/Lesson_5#cl-2:1

Here is the output:


ralphc@home:~/ezsdk/rtsc_tutorial/lesson5$ xdc all
making package.mak (because of package.bld) ...
generating interfaces for package lesson5 (because package/package.xdc.inc is older than package.xdc) ...
configuring prog.x64P from package/cfg/prog_x64P.cfg ...
cl64P prog.c ...
cl64P package/cfg/prog_x64P.c ...
lnk64P prog.x64P ...
configuring prog.x86U from package/cfg/prog_x86U.cfg ...
cl86U prog.c ...
cl86U package/cfg/prog_x86U.c ...
package/cfg/prog_x86U.c: In function âxdc_runtime_System_printfExtend__Iâ:
package/cfg/prog_x86U.c:724: error: invalid initializer
package/cfg/prog_x86U.c:804: error: incompatible types when assigning to type âVaListâ from type âstruct __va_list_tag *â
package/cfg/prog_x86U.c:810: error: incompatible types when assigning to type âva_listâ from type âstruct __va_list_tag *â
package/cfg/prog_x86U.c:842: error: incompatible types when assigning to type âVaListâ from type âstruct __va_list_tag *â
gmake: *** [package/cfg/prog_x86U.o86U] Error 1

Here is my config.bld (on Linux):

/*
 *  ======== config.bld ========
 */

var Build = xdc.useModule('xdc.bld.BuildEnvironment');

var C64P = xdc.useModule('ti.targets.C64P');
//var GCC = xdc.useModule('gnu.targets.Mingw');
var GCC = xdc.useModule('gnu.targets.Linux86');

/* modify to match %c6xtools% */
//C64P.rootDir = "C:/Program Files/Texas Instruments/ccsv4/tools/compiler/c6000";
C64P.rootDir = "/home/ralphc/ezsdk/ti-ezsdk_dm816x-evm_5_01_01_80/cgt6x_7_2_2";
//C64P.ccOpts.prefix = "--no_compress";

C64P.platform = 'ti.platforms.sim64Pxx';

/* modify to match %gcctools% */
//GCC.rootDir = "c:/rtsc/MinGW";
GCC.rootDir = "/usr/"
GCC.ccOpts.prefix = "-O2";

Build.targets = [C64P, GCC];

Please can someone help?

Thanks,
Ralph

  • Hi Ralph, for me it works withouut problems concerning va_list, but I assume it 'only' depends on gcc version and/or settings, how va_list is handled - I have this one running:

    gcc (SUSE Linux) 4.5.0 20100604 [gcc-4_5-branch revision 160292]

    Regards,
    Joern.

  • Hi Joern,

    thanks for your reply. When I run "gcc -v" it gives me:

    Using built-in specs.
    Target: x86_64-linux-gnu
    Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.5-8' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.4 --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
    Thread model: posix
    gcc version 4.4.5 (Debian 4.4.5-8)

    as well as a whole load of other information but nothing that refers to va_list. Annoyingly the lessons don't state which version of gcc to use. Should my gcc also be targeting 32bit x86 do you think?

    Ralph

     

  • Hi Ralph, yes, I assume you are right, and try to targeting 32bit, as the message

    error: invalid initializer

    now seems to make sense: the XDC generated code does not explicitely restrict to long, and so the initializer might be long long there because of the 64 bit, and that might not fit and be the true reason...

    Besides, I tried with my installed 4.4 version of gcc and as well all worked for me (but I have a 32Bit target):

    Using built-in specs.
    Target: i586-suse-linux
    Configured with: ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib --enable-languages=c,c++,objc,fortran,obj-c++,java,ada --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.4 --enable-ssp --disable-libssp --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap --with-slibdir=/lib --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --program-suffix=-4.4 --enable-linux-futex --without-system-libunwind --with-arch-32=i586 --with-tune=generic --build=i586-suse-linux
    Thread model: posix
    gcc version 4.4.1 [gcc-4_4-branch revision 150839] (SUSE Linux)

    Regards,
    Joern.

    P.S. Concerning the initializer that's not actually clear for me, as there a parameter type VaList occurs (or obscures?) - however here is written nothing about which bit depths Linux86 means, but above there all Windows targets are 32 bits, and maybe for 64 bits a different target where needed, like Linux86-64...

     

  • I just got hold of a 32 bit machine and yes it compiles on that.

    So XDC etc only runs properly when GCC is built for a 32 bit target. Nice. I would have thought it would work for the 64 bit target given that's what GCC is mostly nowadays (who bought a 32 bit PC recently?)!

    Any suggestions for a work around? I'm a newbie to RTSC hence my following the tutorial and am not that keen on digging into the XDC source code to work out where the typedefs have gone wrong.

    Ralph

  • Ralph said:

    I just got hold of a 32 bit machine and yes it compiles on that.

    So XDC etc only runs properly when GCC is built for a 32 bit target. Nice. I would have thought it would work for the 64 bit target given that's what GCC is mostly nowadays (who bought a 32 bit PC recently?)!

    Any suggestions for a work around? I'm a newbie to RTSC hence my following the tutorial and am not that keen on digging into the XDC source code to work out where the typedefs have gone wrong.

    I don't have access to a 64-bit gcc (yet) but, ...  You can try to specify that the target you're building for is 32-bit.  You can do this by adding the -m32 option to the compiler.  Simply change the following line (in your config.bld)

        GCC.ccOpts.prefix = "-O2";

    to

        GCC.ccOpts.prefix = "-m32 -O2";

    As suggests, there should probably be a target for 64-bit hosts and we should "fix" the existing Linux86 target to force -m32 to be used (if this fixes the problem).

    For what it's worth: VaList is typedef'd to be va_list in the header $XDCROOT/packages/xdc/std.h.  It's not clear why this would be a problem but va_list usage is a constant source of portability issues.  No doubt there is something that can/should be done in xdc/runtime/System.xdt to make the code more portable.

  • The problem is that our code assumes that va_list is defined as char* and that simple copy is safe. However, on some architectures va_list is an array, and copy does not work. We should probably figure out if we can check for va_copy and use it when available. Here is a thread with more:
    http://www.velocityreviews.com/forums/t437602-varargss-doubt.html

    Look for the first post by Chris Torek.

  • Hi, I tried putting in the "-m32" but it seems to fail in a different way to before:

    ralphc@home:~/ezsdk/rtsc_tutorial/lesson5$ xdc all
    making package.mak (because of package.bld) ...
    generating interfaces for package lesson5 (because package/package.xdc.inc is older than package.xdc) ...
    configuring prog.x64P from package/cfg/prog_x64P.cfg ...
    cl64P prog.c ...
    cl64P package/cfg/prog_x64P.c ...
    lnk64P prog.x64P ...
    configuring prog.x86U from package/cfg/prog_x86U.cfg ...
    cl86U prog.c ...
    cl86U package/cfg/prog_x86U.c ...
    In file included from /usr//include/features.h:378,
                     from /usr//include/limits.h:27,
                     from package/cfg/prog_x86U.c:696:
    /usr//include/gnu/stubs.h:7:27: error: gnu/stubs-32.h: No such file or directory
    gmake: *** [package/cfg/prog_x86U.o86U] Error 1

    I'll keep using the 64 bit compiler for the time being but will be aware of this issue. It would be nice if someone at TI could fix the issue at some point.

    Cheers,

    Ralph

  • Ralph said:

    Hi, I tried putting in the "-m32" but it seems to fail in a different way to before:

    ralphc@home:~/ezsdk/rtsc_tutorial/lesson5$ xdc all
    making package.mak (because of package.bld) ...
    generating interfaces for package lesson5 (because package/package.xdc.inc is older than package.xdc) ...
    configuring prog.x64P from package/cfg/prog_x64P.cfg ...
    cl64P prog.c ...
    cl64P package/cfg/prog_x64P.c ...
    lnk64P prog.x64P ...
    configuring prog.x86U from package/cfg/prog_x86U.cfg ...
    cl86U prog.c ...
    cl86U package/cfg/prog_x86U.c ...
    In file included from /usr//include/features.h:378,
                     from /usr//include/limits.h:27,
                     from package/cfg/prog_x86U.c:696:
    /usr//include/gnu/stubs.h:7:27: error: gnu/stubs-32.h: No such file or directory
    gmake: *** [package/cfg/prog_x86U.o86U] Error 1

    I'll keep using the 64 bit compiler for the time being but will be aware of this issue. It would be nice if someone at TI could fix the issue at some point.

    For what it's worth: this error indicates that your gcc/glibc is not configured to support building 32-bit executables on your beautiful 64-bit host.   It looks like you'd need to install the appropriate multlib release of glibc.

    To properly support 64-bit builds,  xdc/runtime/System.xdt needs to use va_copy _and_ you need a 64-bit XDC target (that defines the appropriate sizes and alignments for the various data types produced by the compiler in 64-bit mode for an x86 architecture).  As it stands, the pre-built libraries think pointers are 32-bit wide but your compiler thinks they are 64-bits wide.