EK-TM4C123GXL: SDK Makefile makedef - adding a library

OK this works as a hack - not sure its the best solution. In the make file list the dependencies as inputs. So in my case, where code is called "sin" what I needed to add was:

${COMPILER}/sin.axf: ${ROOT}/utils/uartstdio.o
${COMPILER}/sin.axf: ${ROOT}/driverlib/${COMPILER}/libdriver.a

This was taken from the timers example - which had a similar hack in it.

Hello David,

Sorry for the delay in reply here - we had holiday on Friday in the US.

I'm honestly struggling to follow what you are doing here and trying to resolve.

The code you mentioned here:

David Summers said:

Now when i come to link it, with a make file that reads makedef - it has several missing functions, I can see these defined as extern in the relevant header files. A bit of digging, and what is clear is it needs to be linked with driverlib/gcc/libdriver.a - but checking the makedef file I don't see how to add that to the linking stage. It just has:

    ${LD} -T $${ldname}                                                   \
          --entry ${ENTRY_${notdir ${@:.axf=}}}                           \
          ${LDFLAGSgcc_${notdir ${@:.axf=}}}                              \
          ${LDFLAGS} -o ${@} $(filter %.o %.a, ${^})                      \
          '${LIBM}' '${LIBC}' '${LIBGCC}'

Those are just artifacts of the build script used to compile the SDK package and have no bearing on using any example projects. They honestly shouldn't have been included but the scripts weren't setup to scrub them out as a final step. In any case, the makefile's and makedefs file have no purpose.

David Summers said:

arm-none-eabi-ld -T sin.ld --entry ResetISR --gc-sections -o gcc/sin.axf gcc/sin.o gcc/startup_gcc.o /home/summers/TIscratch/lib/gcc/arm-none-eabi/11.2.0/../../../../arm-none-eabi/lib/thumb/libm.a /home/summers/TIscratch/lib/gcc/arm-none-eabi/11.2.0/../../../../arm-none-eabi/lib/thumb/libc.a /home/summers/TIscratch/lib/gcc/arm-none-eabi/11.2.0/thumb/libgcc.a ../../driverlib/gcc/libdriver.a
arm-none-eabi-ld: gcc/sin.o: in function `InitConsole':
sin.c:(.text.InitConsole+0x3a): undefined reference to `UARTStdioConfig'
arm-none-eabi-ld: gcc/sin.o: in function `main':
sin.c:(.text.startup.main+0x12): undefined reference to `UARTprintf'
arm-none-eabi-ld: sin.c:(.text.startup.main+0x1a): undefined reference to `UARTprintf'
arm-none-eabi-ld: sin.c:(.text.startup.main+0x3e): undefined reference to `UARTprintf'

If that is the only issue you are trying to resolve and its just the UART functions that are triggering build errors, then this is just the fact that you don't have uartstdio properly linked into your project.

Our TivaWare Getting Started Guide covers how to do this properly in Section 3.1: https://www.ti.com/lit/pdf/spmu373

See if following that resolves your issues.

Best Regards,

Ralph Jacobi

Yes I realised that the makedef had $(filter %.o %.a, ${^})  - so it says I can pass .o or .a files to the makefile, so have stuck with:

${COMPILER}/sin.axf: ${ROOT}/utils/uartstdio.o
${COMPILER}/sin.axf: ${ROOT}/driverlib/${COMPILER}/libdriver.a

I think my problem is with programming style - the  ${ROOT}/utils/uartstdio.o builds a files in the utils directory, and these are out of tree. So "make clean" doesn't remove these files.

What I'd usually do is have the makefile execute a make in another directory, that owns that directory.

So think difference here is just down to programming style. I'm happy to use your style though.

And just back after travel on business, and read SPMU373. Useful document.

Should clarify, I'm using the SDK under linux, with cross compiled gcc+binutils+newlib. So I don't use the CCS. Still though yes can link, and just name in the makefile. Must admit never considered how a link behaves in a make environment, e.g. what counts as an update, just the source, or source and link, or either source or link.

What was probably more useful was section 7.2 on the interrupts, and also what can be set up in the boot process.

Hi David,

I see, interesting - so the included Makefile's in the SDK are basically giving you the basis for putting together links and example projects through Linux then? If so that's new info for me... I always had thought they were leftovers and not useful without the rest of the build script program surrounding them but maybe I did not understand their standalone usage to build components in Linux environments.

Glad that you found some of that document to be useful even if a lot of it is CCS focused (most newcomers for TM4C start there).

Best Regards,

Ralph Jacobi

And just tried installing CCS Studio - it refused to install, because I have a  64bit operating system, it insisted on a 32 bit operating system!

Must admit - I find the makefile fairly convenient  ...

OK solved the 32bit libc problem, by installing the glibc version. Up to now I've been pure 64bit.

Two other problems, libcrypt.so.1 and libtinfo.so.5 - alas I'm on libcrypt.so.2 and libtinfo.so.6:

ls -l /usr/lib/libcrypt.* /usr/lib/libtinfo.*
lrwxrwxrwx 1 root root     17 Feb 24 20:47 /usr/lib/libcrypt.so -> libcrypt.so.2.0.0
lrwxrwxrwx 1 root root     17 Feb 24 20:47 /usr/lib/libcrypt.so.2 -> libcrypt.so.2.0.0
-rwxr-xr-x 1 root root 165824 Feb 24 20:47 /usr/lib/libcrypt.so.2.0.0
-rw-r--r-- 1 root root     24 Feb  3 21:16 /usr/lib/libtinfo.so
lrwxrwxrwx 1 root root     16 Feb  3 21:16 /usr/lib/libtinfo.so.6 -> libncursesw.so.6

Hi David,

Not sure if that is related to CCS install but if so you can check w/ CCS team. Also there may be a Linux specific CCS installation you can use. Not sure. Might be worth making a new thread to get routed to that team though - make sure to use Code Composer Studio / CCS as your 'Part Number'.

Best Regards,

Ralph Jacobi