Fail during building distortosTest

[Adam Mierzwiak]

Hi,

I configured CMake to use DiscoveryF4, went according to manual on page with cmake-gui.

Ninja is building distortos, but during ninja distortosTest:

[48/48] Linking CXX executable test/distortosTest.elf
FAILED: test/distortosTest.elf test/distortosTest.bin test/distortosTest.dmp test/distortosTest.hex test/distortosTest.lss

.....

/usr/bin/objcopy: Unable to recognise the format of the input file

How can I fix it?

Best regards

Adam

[Freddie Chopin]

Hello Adam!

Hmm... That is strange, but CMake does never stop puzzling me (; Could
you please compress your whole output folder, upload it somewhere and
post a link to the file here? I assume you are using distortos 0.7.0,
but what version of the toolchain do you have installed? Could you also
share the exact commands you executed to configure the build folder?
Try to build with `ninja -v distortosTest`, this will show you the
exact commands that were executed. If possible, do `ninja clean`, then
`ninja -v distortosTest` and post the log in here.

If my suspicion is correct, maybe you first had the output folder
configured one way (possibly a completely wrong configuration?), then
tried to reconfigure it (without deleting it) to a different board? I'm
not sure this is possible at all, but maybe it is. In cases like this
the only solution is to delete the build folder entirely and start from
scratch. Even if change of the most basic CMake options (like the
change of toolchain file) is technically possible in a configured tree,
any such attempt will produce a configuration which is broken beyond
repair. Try with a new build folder and see whether it helps.

Note that CMake tries to use /usr/bin/objcopy, while it should be using
arm-none-eabi-objcopy. CMAKE_OBJCOPY is not set explicitly by
distortos, however in here (as well as the CI server and several other
PCs I tried) it is properly detected to have the same triple as the
compilers. If it doesn't work on your side with a clean build folder,
than maybe it should actually be set explicitly... In this case you
could try setting that manually via cmake-gui - just add a new entry
CMAKE_OBJCOPY with the value "<path-to-the-toolchain>/bin/arm-none-
eabi-objcopy" (quite possible that you will have to do the same thing
for OBJDUMP or some other tools). Or modify the toolchain file to set
this variable(s) and see whether it helps (note that after any change
to toolchain file you should completely delete the build folder and
start from scratch!).

Let me know what you'll find out!

Regards,
FCh

[Adam Mierzwiak]

Hello Freddie,

It is version 0.7

I was able to fix the problem. Probably the rootcause was that I mixed steps 2-4 from manual.

First I'v done according to points but later run cmake-gui.

ninja clean was not enough, so I cleaned output folder with rm command and now it compiles.

Best regards

Adam

[Freddie Chopin]

Hello again Adam!

On Mon, 2019-05-13 at 06:55 -0700, Adam Mierzwiak wrote:
> I was able to fix the problem. Probably the rootcause was that I
> mixed steps 2-4 from manual.
> First I'v done according to points but later run cmake-gui.

This should not happen anyway (at least from my limited experience with
CMake). If your build folder is initialized correctly, you can do
almost whatever you want with it, including running cmake-gui as many
times as you want and changing any of the **non-advanced** options.

Which advanced options can be changed is a different thing, but some of
them really cannot be modified safely and it's a pity that CMake allows
doing it. If in doubt, you can always modify compiler and linker flags
(if you use invalid flags then it is your problem [; ) and
CMAKE_BUILD_TYPE + some of the less important ones like
CMAKE_EXPORT_COMPILE_COMMANDS or CMAKE_VERBOSE_MAKEFILE. I would
certainly _NOT_ recommend changing any other advanced option: they
either have no use for an embedded project or changing them will most
likely brake your build folder beyond repair. This is especially about
all the advanced options that select compiler executables,
CMAKE_TOOLCHAIN_FILE and CMAKE_MAKE_PROGRAM.

(Actually I just noticed that CMAKE_TOOLCHAIN_FILE is not an advanced
option, which I hope can be changed.)

If possible, I would be still very much interested in how you got to
that erroneous state so I could reproduce it and give warnings where
possible. This would be really helpful!

> ninja clean was not enough, so I cleaned output folder with rm
> command and now it compiles.

Yes, when something as fundamental as toolchain component is wrong, the
only "solution" is to just delete such folder completely. Doing a
"clean" actually does not touch any of the CMake-generated files, so it
has no way to fixing a problem like the one you saw.

Anyway - I'm glad that you fixed your initial issue and I hope that you
won't face other roadblocks in the near future (;

Regards,
FCh