Notice: We have migrated to GitLab launching 2024-05-01 see here:

#3450 assigned defect

Space character in path breaks rtems build on Linux

Reported by: Gedare Bloom Owned by: Gedare Bloom
Priority: normal Milestone: Indefinite
Component: build Version:
Severity: normal Keywords:
Cc: Blocked By:


With RTEMS sometime after the bsp source reorganization, I now encounter errors when compiling RTEMS in a path that has a space in the name. This used to work. I will try to bisect to find the commit that makes it break. The current thought is that one of our custom automake scripts is not handling the path nicely.

make[4]: Entering directory '/media/gedare/Seagate Expansion
Making all-am in .
Making all-am in sparc
make[5]: Entering directory '/media/gedare/Seagate Expansion
make[5]: * No rule to make target 'all-am'. Stop.
make[5]: Leaving directory '/media/gedare/Seagate Expansion
Makefile:656: recipe for target 'sparc' failed
* [sparc] Error 2

Change History (6)

comment:1 Changed on 06/08/18 at 14:50:48 by Joel Sherrill

I duplicated this on Centos with the native filesystem.

sparc-rtems5-ranlib libscore.a
gmake[5]: * No rule to make target ../../include/rtems/score/cpuopts.h', needed by all-am'. Stop.

My RTEMS source was under a directory with no spaces. But the build directory had a space in the final component. Based on Gedare's report, I think it doesn't matter where the space is in the path.

Build directory: /home/joel/rtems-work/test build
RTEMS Source:    /home/joel/rtems-work/rtems

comment:2 Changed on 10/14/18 at 00:53:10 by Joel Sherrill

Milestone: 5.1Indefinite
Version: 5

comment:3 Changed on 11/14/18 at 15:25:08 by Joel Sherrill

This is the incredibly old GNU make issue which was originally filed in 2002 and has NOT had an update since 2015.

I am recommending we mark this as Won't Fix and add a note to the Users Guide recommending that users not include a space (or other special characters) in their build or installation directories.

comment:4 Changed on 11/14/18 at 22:58:41 by Chris Johns

Should we add a check to configure?

comment:5 in reply to:  4 Changed on 11/14/18 at 23:16:58 by Joel Sherrill

Replying to Chris Johns:

Should we add a check to configure?

Which configure? There are so many places this could break. If we do anything, I would say add it to sb-check for work directory and sb-setbuilder for prefix. GCC, Binutils, GDB, Newlib, Qemu, etc. all use make to build. We can't change every configure on every program. RSB checking would probably catch users before they get too far down the path.

comment:6 Changed on 11/14/18 at 23:53:05 by Chris Johns

From the ticket I assumed the break has happened with rtems.git so I am asking if the top level configure does a check?

Note: See TracTickets for help on using tickets.