RTEMS 4.10 i386 undefined reference to `rtems_bdbuf_configuration'

Joel Sherrill joel at rtems.org
Mon Sep 7 19:53:58 UTC 2020

On Mon, Sep 7, 2020 at 2:40 PM Heinz Junkes <junkes at fhi-berlin.mpg.de>

> > On 7. Sep 2020, at 21:18, Joel Sherrill <joel at rtems.org> wrote:
> >
> >
> > It needs to be in an object file defined between   rtemsTestData.o and
>   -lCom. Otherwise, there are configuration symbols lacking and the dummy
> configuration will get pulled in.
> >
> >
> Unfortunately I do not understand that. These are all object files?

The .o files that constitute your application are the base of what gets
pulled in. They have unresolved dependencies and those unresolved
dependencies are attempted to be resolved with the libraries (-l).  The
configuration structures and variables generated by confdefs.h are part of
the application .o's. In librtemscpu.a in RTEMS < 5.x, there is a "dummy
configuration" which is sufficient for simple applications and satisfying
link probes when you build with a BSP. But if you end up only partially
declaring the configuration data items needed in your application .o's,
then the linker will try to satisfy the unresolved by pulling in from the
libraries. Since there is a rather complete configuration declaration in
dummy, it is overlapping the configuration you did in your application and
you are getting the duplicate symbols.

I think ensuring that the bdbuf symbol is defined in an object listed
before any libraries will ensure it is forced in before a dummy version
from the library is pulled in.

Another approach which is a bit more brutal is to delete dummy.o from
librtemscpu.a and then you will just get undefined symbols for the missing
configuration elements. Copy the library so you can restore it. I think
this command should do the trick:

i386-rtems5-ar dv librtemscpu.a dummy.o

Since some of your configuration is in -lCom, I don't know how the
rtems_config.o in there is referenced. Normally I would expect the RTEMS
Configuration elements to be in an object file. You may need to reference
an undefined symbol in rtems_config.o to force the link.

But you have RTEMS Configuration structures in two object files in two
separate libraries and they conflict.

> [h1 at earth test (7.0 *)]$ make -C O.RTEMS-pc386-qemu -f ../Makefile
> TOP=../../../..     T_A=RTEMS-pc386-qemu install
> make: Entering directory
> '/home/h1/GSOC/rtems5_epics7/QtC-epics-base/modules/libcom/test/O.RTEMS-pc386-qemu'
> /home/travis/.rtems/bin/i386-rtems4.10-g++
> -B/home/travis/.rtems/i386-rtems4.10/pc686/lib/ -specs bsp_specs -qrtems
>  -o libComTestHarness -static
> -L/home/h1/GSOC/rtems5_epics7/QtC-epics-base/lib/RTEMS-pc386-qemu
>  -L/home/travis/.rtems/i386-rtems4.10/pc686/lib/    -mtune=pentiumpro -u
> POSIX_Init -Wl,-Ttext,0x100000         epicsTypesTest.o epicsInlineTest1.o
> epicsInlineTest2.o epicsInlineTest3.o epicsInlineTest4.o epicsCalcTest.o
> epicsAlgorithmTest.o epicsMathTest.o epicsMMIOTest.o epicsEllTest.o
> epicsEnvTest.o epicsEnvUnsetTest.o epicsErrlogTest.o epicsStdioTest.o
> epicsStdlibTest.o epicsSockResolveTest.o epicsStringTest.o epicsTimeTest.o
> epicsThreadTest.o epicsThreadClassTest.o epicsThreadOnceTest.o
> epicsThreadPriorityTest.o epicsThreadPrivateTest.o epicsThreadHooksTest.o
> epicsThreadPoolTest.o epicsExitTest.o epicsTimerTest.o ringPointerTest.o
> ringBytesTest.o epicsEventTest.o epicsMutexTest.o epicsSpinTest.o
> epicsAtomicTest.o macDefExpandTest.o cvtFastTest.o macLibTest.o aslibtest.o
> taskwdTest.o blockingSockTest.o epicsMessageQueueTest.o
> epicsStackTraceTest.o ipAddrToAsciiTest.o osiSockTest.o
> epicsRunLibComTests.o epicsThreadPerform.o epicsMaxThreads.o buckTest.o
> epicsAtomicPerform.o cvtFastPerform.o epicsTimeZoneTest.o
> rtemsTestHarness.o rtemsTestData.o   -lCom       -Wl,--gc-sections -lm
> -lrtemsCom -lc -lrtemscpu -lrtemsCom -lCom -lnfs -lm -lgcc
> /home/h1/GSOC/rtems5_epics7/QtC-epics-base/lib/RTEMS-pc386-qemu/librtemsCom.a(rtems_config.o):(.data+0x0):
> multiple definition of `rtems_libio_init_helper'
> /home/travis/.rtems/i386-rtems4.10/pc686/lib//librtemscpu.a(dummy.o):(.data+0x0):
> first defined here
> /home/h1/GSOC/rtems5_epics7/QtC-epics-base/lib/RTEMS-pc386-qemu/librtemsCom.a(rtems_config.o):(.data+0x4):
> multiple definition of `rtems_libio_supp_helper'
> /home/travis/.rtems/i386-rtems4.10/pc686/lib//librtemscpu.a(dummy.o):(.data+0x4):
> first defined here
> /home/h1/GSOC/rtems5_epics7/QtC-epics-base/lib/RTEMS-pc386-qemu/librtemsCom.a(rtems_config.o):(.data+0x8):
> multiple definition of `rtems_fs_init_helper'
> /home/travis/.rtems/i386-rtems4.10/pc686/lib//librtemscpu.a(dummy.o):(.data+0x8):
> first defined here
> /home/h1/GSOC/rtems5_epics7/QtC-epics-base/lib/RTEMS-pc386-qemu/librtemsCom.a(rtems_config.o):(.data+0xc):
> multiple definition of `rtems_libio_number_iops'
> /home/travis/.rtems/i386-rtems4.10/pc686/lib//librtemscpu.a(dummy.o):(.data+0xc):
> first defined here
> /home/h1/GSOC/rtems5_epics7/QtC-epics-base/lib/RTEMS-pc386-qemu/librtemsCom.a(rtems_config.o):(.bss+0x0):
> multiple definition of `rtems_telnetd_maximum_ptys'
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20200907/096ba875/attachment.html>

More information about the users mailing list