name clashes in RTEMS libraries
Till Straumann
strauman at SLAC.Stanford.EDU
Tue Mar 11 00:00:52 UTC 2003
I found a couple of name clashes in RTEMS
(CPU: powerpc, BSP: mvme2307):
- get_pty() defined in
c/src/libnetworking/pppd/sys-rtems.c
c/src/libnetworking/rtems_telnetd/pty.c
- printk() defined in
cpukit/libcsupport/src/printk.c
c/src/lib/libbsp/powerpc/shared/console/polled_io.c
- drand48() defined in
c/src/libnetworking/pppd/magic.c
newlib/libc/stdlib/drand48.c
- mrand48() defined in
c/src/libnetworking/pppd/magic.c
newlib/libc/stdlib/mrand48.c
- srand48() defined in
c/src/libnetworking/pppd/magic.c
newlib/libc/stdlib/srand48.c
Also, I'd like to throw in my two cents on this:
I'm not sure if things like the webserver, pppd
rtems_shell etc. should really be part of the 'super libraries'
librtemscpu.a/librtemsbsp.a.
The example of telnetd, e.g. shows that telnetd/pty can
perfectly be maintained/built outside of the RTEMS tree.
(http://www.slac.stanford.edu/~strauman/rtems/telnetd/index.html)
IMO, those bits should be kept in separate libraries.
The reason for this is the following:
When you build a system including a run-time loader (such
as esh or CEXP), the initial system must contain most parts
of the basic libraries (libc, RTEMS managers etc.).
Which parts of the core libraries are linked into the
system is a 'configuration' issue (size vs. functionality
tradeoff).
I currently use special linker scripts to taylor a system
to my needs. Since these scripts have to be hand-tuned
(e.g. deleting unwanted library parts), it makes the task
more difficult if all subsystems are contained in a few
huge libraries (contrast this with the situation where we
had 'libpppd', 'libblock', etc. - it is much easier to
identify modular entities).
-- Till
More information about the users
mailing list