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.

undefined reference to `atexit' in xdctools 3.22.01.21

Hello,

first: sorry if this is the wrong forum. I didn't find any better one and here are the most xdc related questions....

Following the "xdctools getting started guide", I tried to implement my own minimal example. After a bit of work, it's almost working, but I get an undefined reference to `atexit`. It seems that this was a known bug in elder xdctools and this post suggests that it should be fixed in my version (3.22.01.21).

What's wrong and how can I fix it? For now, I'm not allowed to update xdc...

That's the output with the error:

----------------------------8<------------------------------------

gru@pc-cm-gru-virtlinux1 % make clean hello
rm -f hello
rm -f hello.o
rm -Rf mycfg
xs xdc.tools.configuro -t gnu.targets.arm.GCArmv7A -b ./config.bld mycfg.cfg
making package.mak (because of package.bld) ...
generating interfaces for package mycfg (because package/package.xdc.inc is older than package.xdc) ...
configuring mycfg.pv7A from package/cfg/mycfg_pv7A.cfg ...
clv7A package/cfg/mycfg_pv7A.c ...
/opt/blafasel/toolchain-arm/opt/ext-toolchain/bin/arm-none-linux-gnueabi-gcc -march=armv7-a -I"/opt/ti/xdctools_3_22_01_21/packages" -I"/opt/ti/xdctools_3_22_01_21/packages" -I"/home/gru/projects/tests/mycfg/.."  -Dxdc_target_types__="gnu/targets/arm/std.h" -Dxdc_target_name__=GCArmv7A -Dxdc_cfg__header__="/home/gru/projects/tests/mycfg/package/cfg/mycfg_pv7A.h" -c hello.c
/opt/blafasel/toolchain-arm/opt/ext-toolchain/bin/arm-none-linux-gnueabi-ld -o hello hello.o -T mycfg/linker.cmd -lstdc++
/opt/blafasel/toolchain-arm/opt/ext-toolchain/bin/arm-none-linux-gnueabi-ld: warning: cannot find entry symbol _start; defaulting to 00009860
/opt/ti/xdctools_3_22_01_21/packages/gnu/targets/arm/rtsv7A/lib/gnu.targets.arm.rtsv7A.av7A(System.ov7A): In function `xdc_runtime_System_Module_startup(void)':
System.c:(.text.xdc_runtime_System_Module_startup__F+0x14): undefined reference to `atexit'
make: *** [hello] Error 1

---------------------------->8------------------------------------

My makefile:

----------------------------8<------------------------------------

CGTOOLS = /opt/blafasel/toolchain-arm/opt/ext-toolchain
CC = $(CGTOOLS)/bin/arm-none-linux-gnueabi-gcc
LNK = $(CGTOOLS)/bin/arm-none-linux-gnueabi-ld
RTS = -lstdc++
CONFIG = mycfg
XDCTARGET = gnu.targets.arm.GCArmv7A


%/linker.cmd %/compiler.opt : %.cfg
    xs xdc.tools.configuro -t $(XDCTARGET) -b ./config.bld $<

all: hello

.PHONY: clean
.SECONDARY: $(CONFIG)/compiler.opt


%.o : %.c # forget built-in rule

%.o : %.c $(CONFIG)/compiler.opt
    $(CC) $(shell cat $(CONFIG)/compiler.opt) -c $<

hello : hello.o $(CONFIG)/linker.cmd
    $(LNK) -o $@ hello.o -T $(CONFIG)/linker.cmd $(RTS)

clean:
    rm -f hello
    rm -f hello.o
    rm -Rf $(CONFIG)

---------------------------->8------------------------------------

My config.bld:

----------------------------8<------------------------------------

var GCArmv7A = xdc.useModule('gnu.targets.arm.GCArmv7A');

GCArmv7A.rootDir="/opt/blafasel/toolchain-arm/opt/ext-toolchain";
GCArmv7A.LONGNAME="/bin/arm-none-linux-gnueabi-gcc"

---------------------------->8------------------------------------

  • Hmm, I should have read the thread that I linked above to the end.... There are others that have problems with 3.22.01.21, too... Unfortunately the thread ends without a real solution. Is

    "t remove the part of the file that begins with
    %var _utils = xdc.loadCapsule("gnu/targets/linkUtils.xs");
    all the way to the end of the file."

    the best solution I can get? Didn't try it, yet....

    cu

    Markus

  • Markus,

    The linker is unable to find reference to atexit (This is not related to the thread you linked above). 

    For linking, I would recommend using gcc instead of ld. gcc will ensure all the additional linker options are passed during linking.

    In your makefile, please make the following changes:

    CGTOOLS = /opt/blafasel/toolchain-arm/opt/ext-toolchain
    CC = $(CGTOOLS)/bin/arm-none-linux-gnueabi-gcc
    LNK = $(CGTOOLS)/bin/arm-none-linux-gnueabi-gcc
    RTS = -lstdc++
    CONFIG = mycfg
    XDCTARGET = gnu.targets.arm.GCArmv7A


    %/linker.cmd %/compiler.opt : %.cfg
        xs xdc.tools.configuro -t $(XDCTARGET) -b ./config.bld $<

    all: hello

    .PHONY: clean
    .SECONDARY: $(CONFIG)/compiler.opt


    %.o : %.c # forget built-in rule

    %.o : %.c $(CONFIG)/compiler.opt
        $(CC) $(shell cat $(CONFIG)/compiler.opt) -c $<

    hello : hello.o $(CONFIG)/linker.cmd
        $(LNK) -o $@ hello.o -Wl,-T,$(CONFIG)/linker.cmd $(RTS)

    clean:
        rm -f hello
        rm -f hello.o
        rm -Rf $(CONFIG)

    -Vikram.



  • For the benefit of Googlers that land on this thread:

    In my case this strange lack of the 'atexit' symbol as well as a host of other issues (like warnings about 32-bit enum types and other warnings about vfp vs. non-vfp object files being linked together, and undefined __gxxpersonality_v0 (huh? that sounds like C++ land)) were all due to the fact that the xdctools and co. are distributed together with binaries. Those binaries were compiled using some sort of compiler with some sort of flags on some sort of host, all of which *theoretically* should be link-compatible with the object files that your compiler produces. The above suggests that this assumption does not hold. In my case, rebuilding the relevant packages from xdctools with 'xdc all' using the toolchain that's used for the application resolved the issues.

    It would be much cleaner to have a separate source distribution and any number of binary distributions of xdctools. If anybody cares for binary distributions, each can be clearly associated with a toolchain and flags used to build it. The current distribution of source together with artifacts, that came from an undocumented(?) build setup, in one directory tree seems suboptimal in light of the above. At least the above incompatibilities manifested explicitly, but who knows what might be silently going on in the binary linked from  mixed-and-matched object files from different compilers and compile flags. I'd certainly prefer not having any binaries at all -- the above issues I had would not have arisen if xdctools packages had to be built to be used. A build would take an order of magnitude less time than (the same build time plus) figuring out the root cause of these obscure warnings and errors.