Issues stitching in a BSP on latest MacOS

Gedare Bloom gedare at rtems.org
Thu Jun 12 13:41:33 UTC 2014


The automake version is newer than what we have been using. This could
be the problem. You may like to use RSB to build your autotools for
RTEMS and install them to a path that you use while bootstrap/build
RTEMS.

Do you get the same error if you try to bootstrap a vanilla RTEMS
clone?  If yes, then you may like to file a bug report at
https://www.rtems.org/bugzilla/

On Wed, Jun 11, 2014 at 6:09 PM, Mr. Andrei Chichak <groups at chichak.ca> wrote:
> Hi, I’m having some problems getting RTEMS to go together.
>
> I’m using a Mac using MacOS 10.9.3 (Mavericks). After a few false starts, I
> reloaded my tools using source-builder, figured out that cvs was missing,
> had to load Xcode 5 to get the tools that were compatible with Mavericks,
> got cvs sorted. Then had to reload the RTEMS source from the git repository.
> So, basically, everything is fresh and squeaky clean.
>
> My BSP is for an ST32F373, based heavily on the ST32F4 BSP (all I want to do
> for now is stitch it in and get it to compile). I have my BSP stored in a
> folder, I blow out the old BSP, copy new BSP into place, bootstrap, move
> into my testing build folder, configure and make thus:
>
> rm -r rtems/rtems/c/src/lib/libbsp/arm/stm32f37x
> cp -R ~andreichichak/BSP/stm32f37x/
> rtems/rtems/c/src/lib/libbsp/arm/stm32f37x
> cd rtems/rtems
> ./bootstrap -c
> ./bootstrap -p
> ./bootstrap
> cd ../..
>
> rm -r rtems/stm32f37x
> mkdir -p rtems/stm32f37x
> cd rtems/stm32f37x
> ../rtems/configure --target=arm-rtems4.11 --disable-posix
> --disable-networking --disable-cxx --enable-bsp=stm32f37x
> --prefix=/Users/andreichichak/development/rtems/4.11 --disable-samples
> --enable-maintainer-mode
> make RTEMS_BSP=stm32f37x install
>
> I know that there are going to be some crufty flags in these commands, and
> would gladly take your input or a pointer to the official best practice
> commands, but I’m getting this:
>
> . . .
> automake: warning: possible forward-incompatibility.
> automake: At least a source file is in a subdirectory, but the
> 'subdir-objects'
> automake: automake option hasn't been enabled.  For now, the corresponding
> output
> automake: object file(s) will be placed in the top-level directory.
> However,
> automake: this behaviour will change in future Automake versions: they will
> automake: unconditionally cause object files to be placed in the same
> subdirectory
> automake: of the corresponding sources.
> automake: You are advised to start using 'subdir-objects' option throughout
> your
> automake: project, to avoid future incompatibilities.
> mptests/mp01/node2/Makefile.am:9: warning: source file
> '../../../support/init.c' is in a subdirectory,
> mptests/mp01/node2/Makefile.am:9: but option 'subdir-objects' is disabled
> mptests/mp02/node1/Makefile.am:9: warning: source file
> '../../../support/init.c' is in a subdirectory,
> mptests/mp02/node1/Makefile.am:9: but option 'subdir-objects' is disabled
> mptests/mp02/node2/Makefile.am:9: warning: source file
> '../../../support/init.c' is in a subdirectory,
> mptests/mp02/node2/Makefile.am:9: but option 'subdir-objects' is disabled
> mptests/mp03/node1/Makefile.am:9: warning: source file
> '../../../support/init.c' is in a subdirectory,
> mptests/mp03/node1/Makefile.am:9: but option 'subdir-objects' is disabled
> mptests/mp03/node2/Makefile.am:9: warning: source file
> '../../../support/init.c' is in a subdirectory,
> mptests/mp03/node2/Makefile.am:9: but option ‘subdir-objects' is disabled
> . . .
>
> times a bazillion. My guess, automake has been updated and my configure.ac
> files need the subdir-objects option thrown in.
>
> automake (GNU automake) 1.14.1
> Copyright (C) 2013 Free Software Foundation, Inc.
> License GPLv2+: GNU GPL version 2 or later
> <http://gnu.org/licenses/gpl-2.0.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
>
> Written by Tom Tromey <tromey at redhat.com>
>        and Alexandre Duret-Lutz <adl at gnu.org>.
>
> The eventual result is a problem where I get:
>
> tm29/Makefile.am:3: warning: source file
> '../../support/src/tmtests_empty_function.c' is in a subdirectory,
> tm29/Makefile.am:3: but option 'subdir-objects' is disabled
> tm30/Makefile.am:3: warning: source file
> '../../support/src/tmtests_empty_function.c' is in a subdirectory,
> tm30/Makefile.am:3: but option 'subdir-objects' is disabled
> tm30/Makefile.am:3: warning: source file
> '../../support/src/tmtests_support.c' is in a subdirectory,
> tm30/Makefile.am:3: but option 'subdir-objects' is disabled
> tmck/Makefile.am:3: warning: source file
> '../../support/src/tmtests_empty_function.c' is in a subdirectory,
> tmck/Makefile.am:3: but option 'subdir-objects' is disabled
> tmoverhd/Makefile.am:3: warning: source file
> '../../support/src/tmtests_empty_function.c' is in a subdirectory,
> tmoverhd/Makefile.am:3: but option 'subdir-objects' is disabled
> ../../../rtems/tools/build/binpatch.c:42:15: warning: implicit declaration
> of function 'getopt' is invalid in C99 [-Wimplicit-function-declaration]
>   while ((c = getopt(argc, argv, "h")) >= 0)
>               ^
> 1 warning generated.
> configure: WARNING: no configuration information is in lib/libbsp/arm
> make[7]: *** No rule to make target `preinstall'.  Stop.
> make[6]: *** [preinstall-recursive] Error 1
> make[5]: *** [preinstall-recursive] Error 1
> make[4]: *** [preinstall-recursive] Error 1
> make[3]: *** [preinstall-stamp] Error 2
> make[2]: *** [install-recursive] Error 1
> make[1]: *** [install-recursive] Error 1
> make: *** [install-recursive] Error 1
>
>
> Could it be that “preinstall” isn’t being generated because automaker isn’t
> recursing properly?
>
>
> Thanks, I’m clueless (I just wish that I could do one BSP on my own some
> day),
>
> Andrei
>
>
>
> _______________________________________________
> users mailing list
> users at rtems.org
> http://lists.rtems.org/mailman/listinfo/users



More information about the users mailing list