#2540 assigned defect

RSB has problems building into existing directory

Reported by: Simon Williams Owned by: Needs Funding
Priority: normal Milestone: Indefinite
Component: tool/rsb Version: 5
Severity: normal Keywords:
Cc: Blocked By:
Blocking:

Description

Attempting to build the ARM/4.12 BSet using RSB on Fedora 23 X86_64. The RSB repository clone was up to date (22/01/2016). I had previously built the same BSet from the repository up to date as of 09/01/2016. When building newlib, I got the following:

Running configure in multilib subdir thumb/cortex-m7/fpv5-d16/hard
pwd: /home/simon.williams/rtems/rtems-source-builder/rtems/build/arm-rtems4.12-gcc-6-20160117-newlib-2.3.0.20160104-x86_64-linux-gnu-1/build/arm-rtems4.12
mkdir thumb/cortex-m7
mkdir thumb/cortex-m7/fpv5-d16
mkdir thumb/cortex-m7/fpv5-d16/hard
configure: creating cache ./config.cache
checking build system type... x86_64-pc-linux-gnu
checking host system type... arm-unknown-rtems4.12
checking for --enable-version-specific-runtime-libs... yes
checking for a BSD-compatible install... /usr/bin/install -c
checking for gawk... gawk
checking for arm-rtems4.12-ar... /home/simon.williams/rtems/4.12/arm-rtems4.12/bin/ar
checking for arm-rtems4.12-lipo... arm-rtems4.12-lipo
checking for arm-rtems4.12-nm... /home/simon.williams/rtems/rtems-source-builder/rtems/build/arm-rtems4.12-gcc-6-20160117-newlib-2.3.0.20160104-x86_64-linux-gnu-1/build/./gcc/nm
checking for arm-rtems4.12-ranlib... /home/simon.williams/rtems/4.12/arm-rtems4.12/bin/ranlib
checking for arm-rtems4.12-strip... /home/simon.williams/rtems/4.12/arm-rtems4.12/bin/strip
checking whether ln -s works... yes
checking for arm-rtems4.12-gcc... /home/simon.williams/rtems/rtems-source-builder/rtems/build/arm-rtems4.12-gcc-6-20160117-newlib-2.3.0.20160104-x86_64-linux-gnu-1/build/./gcc/xgcc -B/home/simon.williams/rtems/rtems-source-builder/rtems/build/arm-rtems4.12-gcc-6-20160117-newlib-2.3.0.20160104-x86_64-linux-gnu-1/build/./gcc/ -nostdinc -B/home/simon.williams/rtems/rtems-source-builder/rtems/build/arm-rtems4.12-gcc-6-20160117-newlib-2.3.0.20160104-x86_64-linux-gnu-1/build/arm-rtems4.12/thumb/cortex-m7/fpv5-d16/hard/newlib/ -isystem /home/simon.williams/rtems/rtems-source-builder/rtems/build/arm-rtems4.12-gcc-6-20160117-newlib-2.3.0.20160104-x86_64-linux-gnu-1/build/arm-rtems4.12/thumb/cortex-m7/fpv5-d16/hard/newlib/targ-include -isystem /home/simon.williams/rtems/rtems-source-builder/rtems/build/arm-rtems4.12-gcc-6-20160117-newlib-2.3.0.20160104-x86_64-linux-gnu-1/gcc-6-20160117/newlib/libc/include -B/home/simon.williams/rtems/4.12/arm-rtems4.12/bin/ -B/home/simon.williams/rtems/4.12/arm-rtems4.12/lib/ -isystem /home/simon.williams/rtems/4.12/arm-rtems4.12/include -isystem /home/simon.williams/rtems/4.12/arm-rtems4.12/sys-include  -mthumb -mcpu=cortex-m7 -mfpu=fpv5-d16 -mfloat-abi=hard
configure: error: in `/home/simon.williams/rtems/rtems-source-builder/rtems/build/arm-rtems4.12-gcc-6-20160117-newlib-2.3.0.20160104-x86_64-linux-gnu-1/build/arm-rtems4.12/thumb/cortex-m7/fpv5-d16/hard/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
make[1]: *** [configure-target-libgcc] Error 1

Sebastian commented that the binutils being used was out of date and I noticed that it was picking up the binutils from my previous build. I removed the previous build from my PATH, but got the same issue. I examined the logs and discovered that RSB was adding the installation bin directory to the PATH while executing. I renamed the original $PREFIX so that it was no longer building into an existing directory and the build ran successfully.

It appears that RSB will not build newlib successfully if it is installing into the same location as a previous build that does not contain compatible tools.

Change History (18)

comment:1 Changed on Jan 26, 2017 at 7:16:00 AM by Sebastian Huber

Milestone: 4.11.14.11.2

comment:2 Changed on Feb 15, 2017 at 1:37:51 PM by Sebastian Huber

Milestone: 4.11.2Indefinite
Owner: set to Needs Funding
Status: newassigned

comment:3 Changed on Oct 5, 2017 at 7:54:29 AM by Sebastian Huber

The RSB output currently looks like this

RTEMS Source Builder - Set Builder, 4.12 (1f3f21ed306b)
warning: exe: absolute exe found in path: (__chown) /usr/sbin/chown
Build Set: 4.12/rtems-all
Build Set: 4.12/rtems-arm.bset
Build Set: 4.12/rtems-autotools.bset
Build Set: 4.12/rtems-autotools-internal.bset
config: tools/rtems-autoconf-2.69-1.cfg
package: autoconf-2.69-x86_64-linux-gnu-1
building: autoconf-2.69-x86_64-linux-gnu-1
config: tools/rtems-automake-1.12.6-1.cfg
package: automake-1.12.6-x86_64-linux-gnu-1
building: automake-1.12.6-x86_64-linux-gnu-1
cleaning: autoconf-2.69-x86_64-linux-gnu-1
cleaning: automake-1.12.6-x86_64-linux-gnu-1
Build Set: Time 0:00:06.855472
Build Set: 4.12/rtems-autotools-base.bset
config: tools/rtems-autoconf-2.69-1.cfg
package: autoconf-2.69-x86_64-linux-gnu-1
building: autoconf-2.69-x86_64-linux-gnu-1
reporting: tools/rtems-autoconf-2.69-1.cfg -> autoconf-2.69-x86_64-linux-gnu-1.txt
reporting: tools/rtems-autoconf-2.69-1.cfg -> autoconf-2.69-x86_64-linux-gnu-1.xml
config: tools/rtems-automake-1.12.6-1.cfg
package: automake-1.12.6-x86_64-linux-gnu-1
building: automake-1.12.6-x86_64-linux-gnu-1
reporting: tools/rtems-automake-1.12.6-1.cfg -> automake-1.12.6-x86_64-linux-gnu-1.txt
reporting: tools/rtems-automake-1.12.6-1.cfg -> automake-1.12.6-x86_64-linux-gnu-1.xml
installing: autoconf-2.69-x86_64-linux-gnu-1 -> /build/rtems-4.12
installing: automake-1.12.6-x86_64-linux-gnu-1 -> /build/rtems-4.12
cleaning: autoconf-2.69-x86_64-linux-gnu-1
cleaning: automake-1.12.6-x86_64-linux-gnu-1
Build Set: Time 0:00:09.739262
Build Set: Time 0:00:16.598011
config: devel/expat-2.1.0-1.cfg
package: expat-2.1.0-x86_64-linux-gnu-1
building: expat-2.1.0-x86_64-linux-gnu-1
reporting: devel/expat-2.1.0-1.cfg -> expat-2.1.0-x86_64-linux-gnu-1.txt
reporting: devel/expat-2.1.0-1.cfg -> expat-2.1.0-x86_64-linux-gnu-1.xml
config: tools/rtems-binutils-2.29-1.cfg
package: arm-rtems4.12-binutils-2.29-x86_64-linux-gnu-1
building: arm-rtems4.12-binutils-2.29-x86_64-linux-gnu-1
reporting: tools/rtems-binutils-2.29-1.cfg -> arm-rtems4.12-binutils-2.29-x86_64-linux-gnu-1.txt
reporting: tools/rtems-binutils-2.29-1.cfg -> arm-rtems4.12-binutils-2.29-x86_64-linux-gnu-1.xml
config: tools/rtems-gcc-7.2.0-newlib-2.5.0.20170922-1.cfg
package: arm-rtems4.12-gcc-7.2.0-newlib-2.5.0.20170922-x86_64-linux-gnu-1
building: arm-rtems4.12-gcc-7.2.0-newlib-2.5.0.20170922-x86_64-linux-gnu-1
reporting: tools/rtems-gcc-7.2.0-newlib-2.5.0.20170922-1.cfg -> arm-rtems4.12-gcc-7.2.0-newlib-2.5.0.20170922-x86_64-linux-gnu-1.txt
reporting: tools/rtems-gcc-7.2.0-newlib-2.5.0.20170922-1.cfg -> arm-rtems4.12-gcc-7.2.0-newlib-2.5.0.20170922-x86_64-linux-gnu-1.xml
config: tools/rtems-gdb-8.0.1-1.cfg
package: arm-rtems4.12-gdb-8.0.1-x86_64-linux-gnu-1
building: arm-rtems4.12-gdb-8.0.1-x86_64-linux-gnu-1
reporting: tools/rtems-gdb-8.0.1-1.cfg -> arm-rtems4.12-gdb-8.0.1-x86_64-linux-gnu-1.txt
reporting: tools/rtems-gdb-8.0.1-1.cfg -> arm-rtems4.12-gdb-8.0.1-x86_64-linux-gnu-1.xml
config: tools/rtems-tools-4.12-1.cfg
package: rtems-tools-HEAD-1
git: reset: git://git.rtems.org/rtems-tools.git
git: fetch: git://git.rtems.org/rtems-tools.git -> sources/git/rtems-tools.git
git: checkout: git://git.rtems.org/rtems-tools.git => HEAD
git: pull: git://git.rtems.org/rtems-tools.git
building: rtems-tools-HEAD-1
reporting: tools/rtems-tools-4.12-1.cfg -> rtems-tools-HEAD-1.txt
reporting: tools/rtems-tools-4.12-1.cfg -> rtems-tools-HEAD-1.xml
config: tools/rtems-kernel-4.12.cfg
package: arm-rtems4.12-kernel-4.12-1
building: arm-rtems4.12-kernel-4.12-1
reporting: tools/rtems-kernel-4.12.cfg -> arm-rtems4.12-kernel-4.12-1.txt
reporting: tools/rtems-kernel-4.12.cfg -> arm-rtems4.12-kernel-4.12-1.xml
installing: expat-2.1.0-x86_64-linux-gnu-1 -> /build/rtems-4.12
installing: arm-rtems4.12-binutils-2.29-x86_64-linux-gnu-1 -> /build/rtems-4.12
installing: arm-rtems4.12-gcc-7.2.0-newlib-2.5.0.20170922-x86_64-linux-gnu-1 -> /build/rtems-4.12
installing: arm-rtems4.12-gdb-8.0.1-x86_64-linux-gnu-1 -> /build/rtems-4.12
installing: rtems-tools-HEAD-1 -> /build/rtems-4.12
installing: arm-rtems4.12-kernel-4.12-1 -> /build/rtems-4.12
cleaning: expat-2.1.0-x86_64-linux-gnu-1
cleaning: arm-rtems4.12-binutils-2.29-x86_64-linux-gnu-1
cleaning: arm-rtems4.12-gcc-7.2.0-newlib-2.5.0.20170922-x86_64-linux-gnu-1
cleaning: arm-rtems4.12-gdb-8.0.1-x86_64-linux-gnu-1
cleaning: rtems-tools-HEAD-1
cleaning: arm-rtems4.12-kernel-4.12-1
Build Set: Time 0:34:45.297368

The autotools are installed before the other stuff which is installed in one big chunk. Maybe this sequence should be changed to install each component as soon as possible, e.g. Binutils before GCC.

comment:4 in reply to:  3 Changed on Oct 5, 2017 at 10:13:58 PM by Chris Johns

Replying to Sebastian Huber:

The autotools are installed before the other stuff which is installed in one big chunk.

The autotools should be installed to an internally path to be available for the build if required and installed at the end when the build finishes. It is a tricky dependence issue that has been in the RSB from its early days.

Maybe this sequence should be changed to install each component as soon as possible, e.g. Binutils before GCC.

This is dangerous and it should never happen. I will not be supporting any change to do this.

An RSB buildset build must be viewed as a single transaction that must succeed to ensure we are able to say the build installed meets the configuration management requirements. We need to know what we have described in the build is install. If the build fails in any way no part should be installed.

If you are installing over an existing installation you could end up with a hybrid of unknown versions which are not configuration controlled. They may appear to work and subtlety fail and that is dangerous or the failures maybe major such as code not building and we would need to field those report and figure out what is wrong and that is an overhead I would not like the project to have.

The RSB provides the sb-build command that lets you step down from the build sets to control specific parts. It is more complicated and may not work given some the way the build sets have developed over the last 5 or so years.

In respect to this ticket I wonder if the user's path has the install prefix's bin directory in it and this is effecting the packaging being built by referencing the already installed tools.

comment:5 Changed on Oct 6, 2017 at 5:10:30 AM by Sebastian Huber

Ok, now the intention is clear to me, however, the GCC build system adds the prefix to the search paths via:

-B/${prefix}/${target}/bin/ -B/${prefix}/${target}/lib/ -isystem /${prefix}/${target}/include -isystem /${prefix}/${target}/sys-include

From my point of view this is a GCC build system bug. I always delete the prefix before I build anything with RSB.

comment:6 in reply to:  5 Changed on Oct 6, 2017 at 5:31:41 AM by Chris Johns

Replying to Sebastian Huber:

Ok, now the intention is clear to me, however, the GCC build system adds the prefix to the search paths via:

-B/${prefix}/${target}/bin/ -B/${prefix}/${target}/lib/ -isystem /${prefix}/${target}/include -isystem /${prefix}/${target}/sys-include

From my point of view this is a GCC build system bug.

Yes, gcc doing this is not helpful.

I always delete the prefix before I build anything with RSB.

I do from time to time but no always and I suppose I do not see any issues because I incrementally bump the tool versions while a jump could have real issues.

This is tricky to resolve within the RSB. For example if the RSB removed the ${PREFIX} with each build automatically you would not be able to build RTEMS 3rd party libraries with the same prefix you built the tools with because the tools would have been deleted.

comment:7 Changed on Nov 13, 2018 at 6:12:51 AM by Sebastian Huber

Maybe the RSB should warn that there are already tools installed in the prefix and offer an option to remove them.

For example building the latest or1k tool chain failed since I had the previous tools installed in $prefix. During GCC build the Binutils of $prefix are used and not the ones which are newly built.

comment:8 in reply to:  7 ; Changed on Nov 13, 2018 at 6:44:00 AM by Chris Johns

Replying to Sebastian Huber:

Maybe the RSB should warn that there are already tools installed in the prefix and offer an option to remove them.

A prefix can be a shared resource used by a number of packages so what are you asking is removed?

The RSB has no concept or knowledge of what the package actually installs so how would it be able to remove these specific parts. This is what distro packaging systems do.

For example building the latest or1k tool chain failed since I had the previous tools installed in $prefix. During GCC build the Binutils of $prefix are used and not the ones which are newly built.

All I can suggest is you wrap the RSB in the distro system of your choice and deploy the tools that way if you want to track specific files in packages.

I think the real issue is not this but the build. The RSB build of the RTEMS tools should be looking to use the binutils just built however for some reason gcc must be looking in the $prefix before the $PATH and when the $prefix is empty it uses the binutils in the $PATH, after all this is what happens when there are no tools installed. Does an option exist in gcc to control this order?

comment:9 in reply to:  8 ; Changed on Nov 13, 2018 at 6:54:51 AM by Sebastian Huber

Replying to Chris Johns:

Replying to Sebastian Huber:

Maybe the RSB should warn that there are already tools installed in the prefix and offer an option to remove them.

A prefix can be a shared resource used by a number of packages so what are you asking is removed?

What I did is this:

find /build/rtems/5/ -name '*or1k*' | xargs rm -r

Yes, a bit dangerous. Maybe if a find $prefix -name "*$target*" finds something, then we can stop the build. The user has then the choice to remove it on its own or use a --force-build-with-existing-tools option.

The RSB has no concept or knowledge of what the package actually installs so how would it be able to remove these specific parts. This is what distro packaging systems do.

For example building the latest or1k tool chain failed since I had the previous tools installed in $prefix. During GCC build the Binutils of $prefix are used and not the ones which are newly built.

All I can suggest is you wrap the RSB in the distro system of your choice and deploy the tools that way if you want to track specific files in packages.

I think the real issue is not this but the build. The RSB build of the RTEMS tools should be looking to use the binutils just built however for some reason gcc must be looking in the $prefix before the $PATH and when the $prefix is empty it uses the binutils in the $PATH, after all this is what happens when there are no tools installed. Does an option exist in gcc to control this order?

I am not sure if this can be fixed by changes in $PATH. In the GCC build tree there is for example an "as" script which is generated:

grep -r ORIGINAL_AS_FOR_TARGET
gcc/Makefile.in:ORIGINAL_AS_FOR_TARGET = @ORIGINAL_AS_FOR_TARGET@
gcc/configure.ac:ORIGINAL_AS_FOR_TARGET=$gcc_cv_as
gcc/configure.ac:AC_SUBST(ORIGINAL_AS_FOR_TARGET)
gcc/configure.ac:case "$ORIGINAL_AS_FOR_TARGET" in
gcc/exec-tool.in:ORIGINAL_AS_FOR_TARGET="@ORIGINAL_AS_FOR_TARGET@"
gcc/exec-tool.in:    original=$ORIGINAL_AS_FOR_TARGET
gcc/ChangeLog-2005:     * Makefile.in (stamp-as): Use $(ORIGINAL_AS_FOR_TARGET)
gcc/ChangeLog-2005:     (ORIGINAL_AS_FOR_TARGET, ORIGINAL_LD_FOR_TARGET,
gcc/configure:ORIGINAL_AS_FOR_TARGET
gcc/configure:ORIGINAL_AS_FOR_TARGET=$gcc_cv_as
gcc/configure:case "$ORIGINAL_AS_FOR_TARGET" in

It uses absolute paths found during configure time (I guess).

comment:10 in reply to:  9 ; Changed on Nov 14, 2018 at 7:01:36 AM by Chris Johns

Replying to Sebastian Huber:

Replying to Chris Johns:

Replying to Sebastian Huber:

Maybe the RSB should warn that there are already tools installed in the prefix and offer an option to remove them.

A prefix can be a shared resource used by a number of packages so what are you asking is removed?

What I did is this:

find /build/rtems/5/ -name '*or1k*' | xargs rm -r

Yes, a bit dangerous. Maybe if a find $prefix -name "*$target*" finds something, then we can stop the build. The user has then the choice to remove it on its own or use a --force-build-with-existing-tools option.

It is dangerous. An example of the problems this exposes is the lack of an undo, a user attempts a build which fails and the previous working installed tools have been removed. I then get requests to not do this.

I think the real issue is not this but the build. The RSB build of the RTEMS tools should be looking to use the binutils just built however for some reason gcc must be looking in the $prefix before the $PATH and when the $prefix is empty it uses the binutils in the $PATH, after all this is what happens when there are no tools installed. Does an option exist in gcc to control this order?

I am not sure if this can be fixed by changes in $PATH. In the GCC build tree there is for example an "as" script which is generated:

grep -r ORIGINAL_AS_FOR_TARGET
gcc/Makefile.in:ORIGINAL_AS_FOR_TARGET = @ORIGINAL_AS_FOR_TARGET@
gcc/configure.ac:ORIGINAL_AS_FOR_TARGET=$gcc_cv_as
gcc/configure.ac:AC_SUBST(ORIGINAL_AS_FOR_TARGET)
gcc/configure.ac:case "$ORIGINAL_AS_FOR_TARGET" in
gcc/exec-tool.in:ORIGINAL_AS_FOR_TARGET="@ORIGINAL_AS_FOR_TARGET@"
gcc/exec-tool.in:    original=$ORIGINAL_AS_FOR_TARGET
gcc/ChangeLog-2005:     * Makefile.in (stamp-as): Use $(ORIGINAL_AS_FOR_TARGET)
gcc/ChangeLog-2005:     (ORIGINAL_AS_FOR_TARGET, ORIGINAL_LD_FOR_TARGET,
gcc/configure:ORIGINAL_AS_FOR_TARGET
gcc/configure:ORIGINAL_AS_FOR_TARGET=$gcc_cv_as
gcc/configure:case "$ORIGINAL_AS_FOR_TARGET" in

It uses absolute paths found during configure time (I guess).

I think binutils is relocatable so I wonder if the pre-installed tools that have been built and waiting for the whole package to finish building can be used. Does --with-as take a path to an executable?

comment:11 in reply to:  10 ; Changed on Nov 14, 2018 at 7:46:18 AM by Sebastian Huber

Replying to Chris Johns:

Replying to Sebastian Huber:

Replying to Chris Johns:

Replying to Sebastian Huber:

Maybe the RSB should warn that there are already tools installed in the prefix and offer an option to remove them.

A prefix can be a shared resource used by a number of packages so what are you asking is removed?

What I did is this:

find /build/rtems/5/ -name '*or1k*' | xargs rm -r

Yes, a bit dangerous. Maybe if a find $prefix -name "*$target*" finds something, then we can stop the build. The user has then the choice to remove it on its own or use a --force-build-with-existing-tools option.

It is dangerous. An example of the problems this exposes is the lack of an undo, a user attempts a build which fails and the previous working installed tools have been removed. I then get requests to not do this.

I think the real issue is not this but the build. The RSB build of the RTEMS tools should be looking to use the binutils just built however for some reason gcc must be looking in the $prefix before the $PATH and when the $prefix is empty it uses the binutils in the $PATH, after all this is what happens when there are no tools installed. Does an option exist in gcc to control this order?

I am not sure if this can be fixed by changes in $PATH. In the GCC build tree there is for example an "as" script which is generated:

grep -r ORIGINAL_AS_FOR_TARGET
gcc/Makefile.in:ORIGINAL_AS_FOR_TARGET = @ORIGINAL_AS_FOR_TARGET@
gcc/configure.ac:ORIGINAL_AS_FOR_TARGET=$gcc_cv_as
gcc/configure.ac:AC_SUBST(ORIGINAL_AS_FOR_TARGET)
gcc/configure.ac:case "$ORIGINAL_AS_FOR_TARGET" in
gcc/exec-tool.in:ORIGINAL_AS_FOR_TARGET="@ORIGINAL_AS_FOR_TARGET@"
gcc/exec-tool.in:    original=$ORIGINAL_AS_FOR_TARGET
gcc/ChangeLog-2005:     * Makefile.in (stamp-as): Use $(ORIGINAL_AS_FOR_TARGET)
gcc/ChangeLog-2005:     (ORIGINAL_AS_FOR_TARGET, ORIGINAL_LD_FOR_TARGET,
gcc/configure:ORIGINAL_AS_FOR_TARGET
gcc/configure:ORIGINAL_AS_FOR_TARGET=$gcc_cv_as
gcc/configure:case "$ORIGINAL_AS_FOR_TARGET" in

It uses absolute paths found during configure time (I guess).

I think binutils is relocatable so I wonder if the pre-installed tools that have been built and waiting for the whole package to finish building can be used. Does --with-as take a path to an executable?

I have absolutely no confidence in the GCC build system. I am not sure if this will ever work reliably. I would

  1. try to detect that an installation exists in the prefix,
  2. stop building if an installation exists unless a special option is given.

comment:12 Changed on Nov 14, 2018 at 7:47:37 AM by Sebastian Huber

The Ada build has also a problem if there already exists an installation. The install procedure aborts with a file permission error.

comment:13 in reply to:  11 Changed on Nov 15, 2018 at 12:45:51 AM by Chris Johns

Replying to Sebastian Huber:

I have absolutely no confidence in the GCC build system.

I do not know gcc's build system enough to comment. It is a bit of a beast.

I am not sure if this will ever work reliably.

I see value in what you are asking and it raises the important broader question of "What a $prefix tree of RTEMS tools means?". We currently assume a release $prefix is a single release however there are no checks made. You are in fact asking we create a new policy that the RSB has avoided until now. Such a policy will exist for ever so I think it would be good to flesh out what it is and what it means.

I would

  1. try to detect that an installation exists in the prefix,

Does this mean we can update a single variant of a package in the $prefix and not the other variants? Do we allow a user to have an arch of one build and another arch on a different build?

Is the detect test per package or common to all packages? If common to all packages, ie in the RSB's python, how would you implement it? I think a common test is too hard.

A per-package test could be implemented with a worker script called from the config script using $(). I did this in the gdb config to find the Python header and library before building gdb. The issue here is implementing the test in each step that matters in a package's build, ie the binutils and gcc for tool sets.

GCC has the RSB hash embedded in it and can be found with:

$prefix/arm-rtems5-gcc --version | awk ' /.*-gcc/ { print substr($8, 1, length($8) - 1); }'
30da0c720b78eba16a3f5272206c07415368617b

Can an RSB hash be added to the GNU as and ld version string? I think this would be needed to make adding any test worthwhile.

  1. stop building if an installation exists unless a special option is given..

I am not a fan of adding extra options. I do not see a need at this point in time. I feel removing installed files or attempting to automatically clean up is a complex hole we should avoid. We could just document what users need to do if they see warnings or errors.

How would you build more than one variant of a packages, ie different arch tool sets? This feeds back to the per-package vs all packages testing of installed packages.

Do we stop for all build types or just release builds? We have two contexts, a development context where we are working with different tool sets and sometimes in different configurations and then we have the release context. Maybe in the development context a warning is printed and in the release context an error is produced.

comment:14 Changed on Nov 15, 2018 at 10:20:51 AM by Sebastian Huber

I don't have a solution for this problem. Normally I just delete the prefix before I start the RSB. While testing the new or1k tool chain I forgot to do this and got a GCC build error. Even though I know that the RSB build is broken with an existing installation in the prefix I didn't think about this and assumed that the new upstream or1k support in GCC is broken.

comment:15 in reply to:  14 Changed on Nov 17, 2018 at 1:20:21 AM by Chris Johns

Replying to Sebastian Huber:

I don't have a solution for this problem.

I did outline one :)

Normally I just delete the prefix before I start the RSB. While testing the new or1k tool chain I forgot to do this and got a GCC build error.

Even though I know that the RSB build is broken with an existing installation in the prefix

The RSB is not broken, it is doing what it is suppose to do. It is the package that is being built that is broken or it is the configuration in the RSB that could be improved. Adding shell call-outs using $() to check the installed version to the gcc tool set scripts would work but we need an RSB signature in as and ld.

I didn't think about this and assumed that the new upstream or1k support in GCC is broken.

Then please raise this with gcc or fix it's build so we can control where it looks for as. It is a weakness with gcc's build we cannot control the as used.

Adding an RSB signature to as and ld is something that should happen.

comment:16 Changed on Nov 17, 2018 at 6:23:46 PM by Sebastian Huber

It is not just the Binutils that make problems. There are at least five issues in case a tool chain is already present.

  1. The build uses the existing Binutils instead of the ones built right now.
  2. Some header and other files of the existing installation may be used instead of the one from the current sources.
  3. The installation adds only files, it does not remove obsolete files leaving a mixture of old and new files in the prefix.
  4. The Ada installation stops with permission errors.
  5. In case something goes wrong it is not easy to figure out that the reason is an existing installation that interfered.

comment:17 in reply to:  16 ; Changed on Nov 18, 2018 at 9:34:55 PM by Chris Johns

Replying to Sebastian Huber:

It is not just the Binutils that make problems. There are at least five issues in case a tool chain is already present.

  1. The build uses the existing Binutils instead of the ones built right now.

If I used the same prefix as an bare metal ELF tool chain could gcc pick up that assembler?

Do we need more or better documentation on the $prefix in the User manual?

  1. Some header and other files of the existing installation may be used instead of the one from the current sources.

Why is gcc doing this? It seems wrong and dangerous.

  1. The installation adds only files, it does not remove obsolete files leaving a mixture of old and new files in the prefix.

The binutils and gcc do just this as well. The RSB is not a packaging or deployment tool. That is a role I see existing outside of the RTEMS project where specialisation and support can happen.

  1. The Ada installation stops with permission errors.

I thought this was in the Ada build when run from python?

  1. In case something goes wrong it is not easy to figure out that the reason is an existing installation that interfered.

Agreed, but why is it the role of the RSB tool (not the configuration parts) to deal with this?

I have offered a solution and I am willing to review patches.

comment:18 in reply to:  17 Changed on Nov 19, 2018 at 6:13:51 AM by Sebastian Huber

Replying to Chris Johns:

Replying to Sebastian Huber:

It is not just the Binutils that make problems. There are at least five issues in case a tool chain is already present.

  1. The build uses the existing Binutils instead of the ones built right now.

If I used the same prefix as an bare metal ELF tool chain could gcc pick up that assembler?

I don't know.

Do we need more or better documentation on the $prefix in the User manual?

Yes, I didn't find a hint that an existing installation may interfere with the current build.

  1. Some header and other files of the existing installation may be used instead of the one from the current sources.

Why is gcc doing this? It seems wrong and dangerous.

https://devel.rtems.org/ticket/2540#comment:5

  1. The installation adds only files, it does not remove obsolete files leaving a mixture of old and new files in the prefix.

The binutils and gcc do just this as well. The RSB is not a packaging or deployment tool. That is a role I see existing outside of the RTEMS project where specialisation and support can happen.

I think this should be clarified in the documentation.

  1. The Ada installation stops with permission errors.

I thought this was in the Ada build when run from python?

As far as I remember it was an issue in the Python copytree area.

  1. In case something goes wrong it is not easy to figure out that the reason is an existing installation that interfered.

Agreed, but why is it the role of the RSB tool (not the configuration parts) to deal with this?

I have offered a solution and I am willing to review patches.

I think your proposal is fine. I just wanted to highlight that there are multiple problems if you have an existing installation.

Note: See TracTickets for help on using tickets.