What the... * Error -d is not a supported platform

Back again with some news.

As already mentioned in a previous blog, I had to re-install my Kubuntu on VmWare.

Once this was done, I also re-installed the FoxBoard SDK from scratch. However, when running the initial compilation, I quickly got the following error message on the screen, after which the installation ended:

install -p -d     /home/fb/devboard-R2_01/tools/build-R2_12_4/bin
    * Error -d is not a supported platform

I couldn't get any further, also the command ./configure was facing the same problem.

After several tries and a lot of thinking (that hurts, you know!), I decided to analyse the whole installation script (install_svn_sdk.sh).

It took me a bit of time, but I got quite quickly an "eagle's view" on how the installation worked.

I executed the commands step by step on the command line and I saw the error I gave above, appeared when I executed the following command:

A=`yes n | \`make oldconfig 2&> install.log\``

The result I got, was the following:

make tools
make[1]: Entering directory `/home/foxboard/devboard-R2_01'
make -C tools/build install
make[2]: Entering directory `/home/foxboard/devboard-R2_01/tools/build-R2_12_4'
make -C ccdv install BINDIR="/home/foxboard/devboard-R2_01/tools/build-R2_12_4/bin" LIBDIR="/home/foxboard/devboard-R2_01/tools/build-R2_12_4/lib"
make[3]: Entering directory `/home/foxboard/devboard-R2_01/tools/build-R2_12_4/ccdv'
gcc -Wall -Wshadow -I/home/foxboard/devboard-R2_01/target/host/include -O0 -g -fno-omit-frame-pointer    -L/home/foxboard/devboard-R2_01/target/host/lib -Wl,-rpath-link,/home/foxboard/devboard-R2_01/target/host/lib  ccdv.c   -o ccdv
install -p -d /home/foxboard/devboard-R2_01/tools/build-R2_12_4/bin
* Error -p is not a supported platform
make[3]: *** [install] Error 1
make[3]: Leaving directory `/home/foxboard/devboard-R2_01/tools/build-R2_12_4/ccdv'
make[2]: *** [ccdv] Error 2
make[2]: Leaving directory `/home/foxboard/devboard-R2_01/tools/build-R2_12_4'
make[1]: *** [tools] Error 2
make[1]: Leaving directory `/home/foxboard/devboard-R2_01'
make: *** [/home/foxboard/devboard-R2_01/tools/build/bin/aconf] Error 2

Then the search started to find out where the error could come from.

As a last exit, I tried to run the installation as root and to my surprise, I was able to install everything. Only later, it was clear to me as to why that was possible (see further).

Reverting back to a regular user, I tried over and over again, going bit by bit deeper into the problem.

I followed the call to make oldconfig (the one that failed) and when looking to the makefile in ./devboard-R2.01-1, I found out that the target oldconfig was defined as follows:

## oldconfig - Updates the product configuration.
##
.PHONY: oldconfig
oldconfig:      $(AXIS_TOP_DIR)/tools/build/bin/aconf
@$(AXIS_TOP_DIR)/tools/build/bin/aconf -o configure-files/common/AC_common
@touch Makefile

So, first the target $(AXIS_TOP_DIR)/tools/build/bin/aconf in the same makefile was executed. This target was defined as follows:

$(AXIS_TOP_DIR)/tools/build/bin/aconf $(AXIS_TOP_DIR)/tools/build/bin/amconf:
$(MAKE) tools

Here I saw the same makefile was called again, with the target tools. The following was defined for that target:

## tools - Builds and installs all tools on this host.
##
.PHONY: tools
tools:
$(MAKE) -C tools/build install

So, I saw the makefile in /tools/build was called, with target install.

Going to that makefile, I saw the target install was defined as follows:

install:        $(ISUBDIRS) install_e100boot install_fsboot
@echo "Installation of build tools complete."

That means, I had to look for the content of variable $(ISUBDIRS). This was defined as follows:

ISUBDIRS :=
    ccdv \
    scripts \
    aconfig \
    filepp \
    genromfs \
    imgsum \
    mkcramfs \
    mkfs.jffs \
    mkfs.jffs2
    profile \
    sermon \
    sortdir \
    tcptest \

Now I knew what command was filling ./devboard-R2.01-1/tools/build/bin!

When looking close into the makefile, I saw at the beginning the following definition:

INSTALL ?= install -p
export INSTALL

So, here the Linux command install -p was put under the variable INSTALL and then exported to the whole FoxBoard SDK.

That means, everywhere where there was a call to $(INSTALL), it was replaced by install -p.

Finally, I found where the install -p came from!!!

Now, when I executed the command "which install", I saw to my big surprise I was not getting the executable install, located in /usr/bin, but the script install instead, located in ./devboard-R2.01-1!!!

The picture was clear to me now. For one reason or another, the incorrect install was called!
I started digging into the paths and what I see was the following:

- I had extended the standard PATH variable with a couple of paths I'm frequently using, among others, the path ./devboard-R2.01-1.

- But more important: I'd added my personal paths in front of the system paths! So, when looking for the command install, the OS found one in the ./devboard-R2.01-1 directory, so there was no reason to go further along the path to look for another install!

It was clear now: in stead of calling the executable install, all FoxBoard SDK's were in fact calling the script install. Needless to say that a "target" -p indeed resulted in the error given at the top of that article.

Since I knew the real cause, I simply solved it by changing the order the PATH environment variable was build up: first the system directories/paths and only then adding my own paths!!!

This solved the issue, but still I think it's not wise to have a script having the same name as an executable. Therefore, I requested to AcmeSystems if they're willing to change the script install into installfoxsdk (or something like that).

Let's see what the outcome is!

What I've learned is, especially here, that it's very important to know the way the directory structure is traversed, if the OS is looking for an executable.

Also, having a script the same name as an executable isn't a wise choice, but that's my humble opinion.

And finally, why was I able to run the scripts as a root? Well, simply because for the user root, the paths were not "polluted" with the FoxBoard paths. That is, install was really the executable install, not the script install!!!

Learning all the time...