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

[cjohns at plessey.com.au (Chris Johns)]

Ralf Corsepius wrote:
> 
> 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
> 

If you are getting '-lm -lc' from $(LINK_FILES) then I fail to see now
the rule to build $(PGM) in hello/Makefile.in is working for you.

> > 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).
> 

Sure I have no problem with this. It is the '-lm -lc' appearing on the
right side of a makefile rule that is stopping the build. The subject is
a little misleading. Sorry for that.

> > ...
> >
> >  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).
> 

But a file -lm or -lc does not exist anywhere. Make is looking for a
file '-lm'.

> 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.
> 

That could be '-lm' being specified local to a Makefile. I think
paranoia is an example. You might wish to check this example.

> > 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")
> 

Well this is very confusing. I am working of a version built from the
patches. I did notice the resulting tar file was a different size. I
will check this out.

Just looking at the makefiles, the result I am getting seems correct. It
should fail.

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

../rtems-980618/../rtems-980618/configure  --prefix=/ods/egcs/test
--enable-cxx --enable-gmake-print-directory

> 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.
> 

It is not a link problem, it is a makefile problem. I am sure when make
lets the link proceed it will happen without error.

-- 
 Chris Johns  Networks, Plessey Asia Pacfic Pty. Ltd.
  mailto:ccj at acm.org    mailto:cjohns at plessey.com.au