Skip to main content
dsampson92
dsampson92
Associate
January 31, 2013
Question

Linker error when compiling with CodeSourcery

  • January 31, 2013
  • 5 replies
  • 1384 views
Posted on January 31, 2013 at 13:06

Trying to get a linux toolchain up and running to eventually program an STM32L Discovery board.  I have Code Sourcery CodeBench Lite set up in a folder and a Make script set up to build it all.  Right now it's just a skeleton program, consisting of a main.c, startup_stm32l1xx_md.s, and system_stm32l1xx.c.  When I run the script, it compiles for a bit and then I get these errors:

/home/dsampson/arm-dev/arm-gcc/bin/arm-none-linux-gnueabi-gcc -T../stm32_flash.ld -mthumb -mcpu=cortex-m3  -o code.elf startup_stm32l1xx_md.o system_stm32l1xx.o  main.o 

/home/dsampson/arm-dev/arm-gcc/bin/../lib/gcc/arm-none-linux-gnueabi/4.7.2/../../../../arm-none-linux-gnueabi/bin/ld: error: startup_stm32l1xx_md.o: Conflicting architecture profiles M/A

/home/dsampson/arm-dev/arm-gcc/bin/../lib/gcc/arm-none-linux-gnueabi/4.7.2/../../../../arm-none-linux-gnueabi/bin/ld: failed to merge target specific data of file startup_stm32l1xx_md.o

/home/dsampson/arm-dev/arm-gcc/bin/../lib/gcc/arm-none-linux-gnueabi/4.7.2/../../../../arm-none-linux-gnueabi/bin/ld: error: system_stm32l1xx.o: Conflicting architecture profiles M/A

/home/dsampson/arm-dev/arm-gcc/bin/../lib/gcc/arm-none-linux-gnueabi/4.7.2/../../../../arm-none-linux-gnueabi/bin/ld: failed to merge target specific data of file system_stm32l1xx.o

/home/dsampson/arm-dev/arm-gcc/bin/../lib/gcc/arm-none-linux-gnueabi/4.7.2/../../../../arm-none-linux-gnueabi/bin/ld: error: main.o: Conflicting architecture profiles M/A

/home/dsampson/arm-dev/arm-gcc/bin/../lib/gcc/arm-none-linux-gnueabi/4.7.2/../../../../arm-none-linux-gnueabi/bin/ld: failed to merge target specific data of file main.o

I ran readelf on each ot the object files, and both startup and main show up as Cortex M3 v7 object files, but it doesn't recognize the system_stm32l1xx.o file as being valid.  I tried deleting it and recompiling but no luck.  It's the system file I pulled out of the firmware pack for the L1 Discovery board so I would think it's a valid file.  Any ideas what could be going wrong?

    This topic has been closed for replies.

    5 replies

    frankmeyer9
    frankmeyer9
    Associate III
    January 31, 2013
    Posted on January 31, 2013 at 13:15

    I think it would be helpful to post the make file, too.

    Perhaps you have compiled the C file(s) with wrong/missing/default architecture specification, i.e.

    -mcpu

    and

    -march

    settings.

    At least the error messages sound like this.

    dsampson92
    dsampson92Author
    Associate
    January 31, 2013
    Posted on January 31, 2013 at 13:19

    ELF=$(notdir $(CURDIR)).elf                    

    # Tool path

    TOOLROOT=/home/dsampson/arm-dev/arm-gcc/bin

    # Library path

    LIBROOT=/home/dsampson/arm-dev/STM32L1xx/lib/STM32L_Discovery_Firmware_Pack_V1.0.2

    # Tools

    GCC=$(TOOLROOT)/arm-none-linux-gnueabi-gcc

    LD=$(TOOLROOT)/arm-none-linux-gnueabi-gcc

    AR=$(TOOLROOT)/arm-none-linux-gnueabi-ar

    AS=$(TOOLROOT)/arm-none-linux-gnueabi-as

    # Code Paths

    DEVICE=$(LIBROOT)/Libraries/CMSIS/CM3/DeviceSupport/ST/STM32L1xx

    CORE=$(LIBROOT)/Libraries/CMSIS/CM3/CoreSupport

    PERIPH=$(LIBROOT)/Libraries/STM32L1xx_StdPeriph_Driver

    # Search path for standard files

    vpath %.c $(TEMPLATEROOT)

    vpath %.s $(TEMPLATEROOT)

    # Search path for perpheral library

    vpath %.c $(CORE)

    vpath %.c $(PERIPH)/src

    vpath %.c $(DEVICE)

    #  Processor specific

    PTYPE = STM32L1XX_MD

    LDSCRIPT = $(TEMPLATEROOT)/stm32_flash.ld

    STARTUP= startup_stm32l1xx_md.o system_stm32l1xx.o 

    # Compilation Flags

    FULLASSERT = -DUSE_FULL_ASSERT 

    LDFLAGS+= -T$(LDSCRIPT) -mthumb -mcpu=cortex-m3 

    CFLAGS+= -mcpu=cortex-m3 -mthumb 

    CFLAGS+= -I$(TEMPLATEROOT) -I$(DEVICE) -I$(CORE) -I$(PERIPH)/inc -I.

    CFLAGS+= -D$(PTYPE) -DUSE_STDPERIPH_DRIVER $(FULLASSERT)

    # Build executable 

    $(ELF) : $(OBJS)

    $(LD) $(LDFLAGS) -o $@ $(OBJS) $(LDLIBS)

    # compile and generate dependency info

    %.o: %.c

    $(GCC) -c $(CFLAGS) $< -o $@

    $(GCC) -MM $(CFLAGS) $< > $*.d

    %.o: %.s

    $(GCC) -c $(CFLAGS) $< -o $@

    clean:

    rm -f $(OBJS) $(OBJS:.o=.d) $(ELF) startup_stm32l* $(CLEANOTHER)

    debug: $(ELF)

    arm-none-eabi-gdb $(ELF)

    # pull in dependencies

    -include $(OBJS:.o=.d)

    And then in a subfolder where main.c lives:

    TEMPLATEROOT = ..

    CFLAGS = -O0 -g

    ASFLAGS = -g

    OBJS=$(STARTUP) main.o

    include $(TEMPLATEROOT)/Makefile.common

    frankmeyer9
    frankmeyer9
    Associate III
    January 31, 2013
    Posted on January 31, 2013 at 13:47

    And with adding '

    -arch=armv7-m'

    to the cflags ?

    dsampson92
    dsampson92Author
    Associate
    January 31, 2013
    Posted on January 31, 2013 at 20:57

    Same result

    Tesla DeLorean
    Tesla DeLorean
    Guru
    January 31, 2013
    Posted on January 31, 2013 at 23:09

    I think with GNU/GCC I've always used the arm-none-eabi chains for the STM32.

    You should look at the options passed to the assembler and make sure they are coherent with those used by the compiler/linker.

    Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
    Terms & ConditionsAccessibility statement