1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 <2021> 2022 2023 2024 2025 | Index | 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 <2021> 2022 2023 2024 2025 |
<== Date ==> | <== Thread ==> |
---|
Subject: | linking in IOC makefile for RTEMS |
From: | "Siddons, David via Tech-talk" <tech-talk at aps.anl.gov> |
To: | EPICS Tech Talk <tech-talk at aps.anl.gov> |
Date: | Fri, 16 Jul 2021 19:08:28 +0000 |
I have an RTEMS test IOC (generated using makeBaseApp) to which I've added a source file which declares a large array (actually, a compiled-in file system). The Makefile has:
......
# rather than directly into the IOC application, that
# causes problems on Windows DLL builds
myexampleSupport_SRCS += dbSubExample.c
myexampleSupport_SRCS += devmyexampleVersion.c
myexampleSupport_SRCS += myexampleHello.c
myexampleSupport_SRCS += initTrace.c
myexampleSupport_SRCS += tarball.h
myexampleSupport_SRCS += tarball.c
where the tarball files are my additions. The C file contains:
/*
* Declarations for C structure representing binary file epicsRtemsFSImage
*
* WARNING: Automatically generated -- do not edit!
*/
#include <sys/types.h>
const unsigned char epicsRtemsFSImage[] = {
0x74, 0x61, 0x72, 0x62, 0x61, 0x6c, 0x6c, 0x2f, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
.....etc, then:
const size_t epicsRtemsFSImage_size = sizeof(epicsRtemsFSImage);
The EPICS base libraries contain a weak reference to this same symbol (from libcom/RTEMS/init.c) , and I expected this definition to overwrite the weak one, but inspection of the executable only shows the weak one, and the size variable is not referenced at
all. What am I missing? It seems that the tarball file is compiled, but not linked.
Pete.
|