[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

rtems-980618, unix (linux) bsp link failure.



Chris Johns wrote:

> Hi all,
>
> I am getting a makefile error when linking the sample programs. I am not
> sure when this happened as I have not been using the Unix BSP lately.
>
>  make[4]: Entering directory
> `/ods/src/tools/rtems/rtems-980618/linux/c/src/tests/samples/hello'
>  make[4]: *** No rule to make target `-lm', needed by
> `o-linux1/hello.exe'.  Stop.
>  make[4]: Leaving directory
> `/ods/src/tools/rtems/rtems-980618/linux/c/src/tests/samples/hello'

I cannot reproduce your problem:

cd hello; make all
test -d o-linux1 || /bin/mkdir -p -m 0755 o-linux1
/opt/gnu/bin/gcc --pipe   -Wall -ansi -fasm -g
-B/lfs/hermes/embedded/rtems-test/build/linux/posix/lib/ -specs bsp_specs
-qrtems   -O2     -c -o o-linux1/init.o
/lfs/hermes/embedded/rtems-test/rtems-rc-980619/c/src/tests/samples/hello/init.c

/opt/gnu/bin/gcc --pipe -o o-linux1/hello.exe   o-linux1/init.o
/lfs/hermes/embedded/rtems-test/build/linux/posix/lib/no-dpmem.rel
/lfs/hermes/embedded/rtems-test/build/linux/posix/lib/no-event.rel
/lfs/hermes/embedded/rtems-test/build/linux/posix/lib/no-msg.rel
/lfs/hermes/embedded/rtems-test/build/linux/posix/lib/no-mp.rel
/lfs/hermes/embedded/rtems-test/build/linux/posix/lib/no-part.rel
/lfs/hermes/embedded/rtems-test/build/linux/posix/lib/no-signal.rel
/lfs/hermes/embedded/rtems-test/build/linux/posix/lib/no-timer.rel
/lfs/hermes/embedded/rtems-test/build/linux/posix/lib/no-rtmon.rel
/lfs/hermes/embedded/rtems-test/build/linux/posix/lib/libtest.a
/lfs/hermes/embedded/rtems-test/build/linux/posix/lib/librtemsall.a -lm -lc
/opt/gnu/lib/gcc-lib/i586-pc-linux-gnulibc1/egcs-2.90.29/libgcc.a  -lm -lc


> The maths lib is specified in 'make/custom/posix.cfg', with the
> following code and comment:
>
>  # Set them here, otherwise gcc-target-default.cfg will set them to
> values
>  # not working on some os variants (linux-RH5.0, glibc versions 2.0.0 -
> 2.0.7)
>  # These should be available on all unices
>  LIBC_LIBC=-lc
>  LIBC_LIBM=-lm
>
> These are then built up to resided in the LINK_FILES makefile variable

Setting LIBC_XXX at this location disables detection of libc and libm in
gcc-target-default.cfg - This is intentionally (cf. below).

> ...
>
>  LINK_LIBS=\
>      $(LD_LIBS) \
>      $(LIBC_EXTRA_LIBS)  \
>      $(PROJECT_RELEASE)/lib/librtemsall$(LIBSUFFIX_VA) \
>      $(LIBC_LIBM) $(LIBC_LIBC) $(LIBGCC)
>
>  LINK_FILES=\
>      $(START_FILE) \
>      $(LINK_OBJS) \
>      $(LINK_LIBS)
>
> The hello world leaf makefile then does ...
>
>  ${PGM}: $(OBJS) $(LINK_FILES)
>         $(make-exe)
>
> ... which IMO is broken for the Unix BSP. I cannot see now '-lm', or
> even '-lc' can be a dependency.

The basic principle to link a posix BSP is different from other bsps.
Unlike for embedded BSPs, for unix BSPs we apply the default search paths
of gcc. We only add -lm and -lc, but don't a search path to it (ie. libm,
libc, libgcc should be picked up from the default library search path).

I know there is still a bug somewhere, as -lc -lm is passed twice sometimes
when linking (cf. above). I think this may be related to the makefile
fragments pointed out by you, but this shouldn't cause problems.

> The 'gcc -print-file-name=libm.a' does not work on a glibc1 Linux-RH4.0
> machine.
>
> Has anyone got the Unix (Linux) BSP to compile lately ?

Yes, I did - several times, even with Joel's latest snapshot (Linux-2.1.106
SMP/Linux-2.0.33 UP, libc-5.4.46, gcc-2.7.2.3/egcs-1.0.3a). I didn't try
the latest snapshot under solaris yet, but approx. 2-3 weeks ago I had
tried a current snapshot of that time under solaris with several gcc/egcs
variants and complex amd installations - no problem at all (except of the
"host" problem in rtems-glom")

Which options did you use to configure? Maybe there is a problem related to
this. I usually use --prefix=<...> --enable-cxx.

Did you setup LD_LIBRARY_PATH correctly? If using a secondary compiler and
not having set up LD_LIBRARY_PATH correctly, you may receive weird link or
run-time problems.

Ralf.

--
Ralf Corsepius
Forschungsinstitut fuer Anwendungsorientierte Wissensverarbeitung (FAW)
Helmholtzstr. 16, 89089 Ulm, Germany     Tel: +49/731/501-8690
mailto:corsepiu at faw.uni-ulm.de           FAX: +49/731/501-999
http://www.faw.uni-ulm.de