Fresh installation on Ubuntu 18.04.3 - Compilation of patches fails - 'int rand()' was declared 'extern' and later 'static'

linux
#1

Hello there!

I installed the latest release (axoloti-linux-1.0.12-2.deb) of the Axoloti software via dpkg on Ubuntu 18.04.3 LTS. The Software starts fine, asked me to upgrade the firmware on the Axoloti (Version 1.0 first batch) which also worked fine.

The software can connect to the Axoloti, but when I try to run any of the supplied demo patches I always get the same error about the rand() function being redeclared, one time 'extern' and one time 'static'.

An hints and help would be appreciated. Thanks in advance!

-rolf

Generate code complete
Start compiling patch
Compiling patch... with /opt/Axoloti/app/firmware
BDIR = /home/romor001/axoloti/build
FIRMWARE = .
Build precompiled header
arm-none-eabi-g++ -nostdlib -fno-exceptions -fno-rtti -mcpu=cortex-m4 -O3 -fomit-frame-pointer -falign-functions=16 -mfloat-abi=hard -mfpu=fpv4-sp-d16 -Wunused-parameter -DCORTEX_USE_FPU=TRUE -DTHUMB_PRESENT -mno-thumb-interwork -DTHUMB_NO_INTERWORKING -mthumb -DTHUMB -std=c++11 -DARM_MATH_CM4 -D__FPU_PRESENT -fno-math-errno -fno-threadsafe-statics -fno-use-cxa-atexit -Wno-unused-parameter -I/opt/Axoloti/app/CMSIS/Include -I/opt/Axoloti/app/CMSIS/DSP_Lib/Include -I/opt/Axoloti/app/chibios/os/ports/common/ARMCMx/CMSIS/include -I/opt/Axoloti/app/chibios/os/ports/common/ARMCMx -I/opt/Axoloti/app/chibios/os/ports/GCC/ARMCMx -I/opt/Axoloti/app/chibios/os/ports/GCC/ARMCMx/STM32F4xx -I/opt/Axoloti/app/chibios/os/kernel/include -I/opt/Axoloti/app/chibios/os/hal/include -I/opt/Axoloti/app/chibios/os/hal/platforms/STM32F4xx -I/opt/Axoloti/app/chibios/os/hal/platforms/STM32 -I/opt/Axoloti/app/chibios/os/hal/platforms/STM32/GPIOv2 -I/opt/Axoloti/app/chibios/os/hal/platforms/STM32/I2Cv1 -I/opt/Axoloti/app/chibios/os/hal/platforms/STM32/OTGv1 -I/opt/Axoloti/app/chibios/os/hal/platforms/STM32/RTCv2 -I/opt/Axoloti/app/chibios/os/hal/platforms/STM32/SPIv1 -I/opt/Axoloti/app/chibios/os/hal/platforms/STM32/TIMv1 -I/opt/Axoloti/app/chibios/os/hal/platforms/STM32/USARTv1 -I/opt/Axoloti/app/chibios/boards/ST_STM32F4_DISCOVERY -I/opt/Axoloti/app/chibios/ext/fatfs/src -I. -I/opt/Axoloti/app/chibios -I./mutable_instruments -Winvalid-pch -MD -MP -c ./xpatch.h -o /home/romor001/axoloti/build/xpatch.h.gch
In file included from ./axoloti.h:24:0,
from ./xpatch.h:3:
./axoloti_math.h:180:0: warning: "RAND_MAX" redefined
#define RAND_MAX INT32_MAX

In file included from /usr/arm-none-eabi/include/c++/7.3.1/bits/std_abs.h:38:0,
from /usr/arm-none-eabi/include/c++/7.3.1/cmath:47,
from /usr/arm-none-eabi/include/c++/7.3.1/math.h:36,
from /usr/arm-none-eabi/include/fastmath.h:7,
from ./axoloti.h:21,
from ./xpatch.h:3:
/usr/arm-none-eabi/include/stdlib.h:63:0: note: this is the location of the previous definition
#define RAND_MAX _RANDMAX

In file included from ./axoloti.h:24:0,
from ./xpatch.h:3:
./axoloti_math.h: In function 'int rand()':
./axoloti_math.h:181:57: error: 'int rand()' was declared 'extern' and later 'static' [-fpermissive]
attribute ( ( always_inline ) ) _STATICINLINE int rand(void) {
^~~~
In file included from /usr/arm-none-eabi/include/c++/7.3.1/bits/std_abs.h:38:0,
from /usr/arm-none-eabi/include/c++/7.3.1/cmath:47,
from /usr/arm-none-eabi/include/c++/7.3.1/math.h:36,
from /usr/arm-none-eabi/include/fastmath.h:7,
from ./axoloti.h:21,
from ./xpatch.h:3:
/usr/arm-none-eabi/include/stdlib.h:140:5: note: previous declaration of 'int rand()'
int rand (void);
^~~~
Makefile.patch:53: recipe for target '/home/romor001/axoloti/build/xpatch.h.gch' failed
make: *** [/home/romor001/axoloti/build/xpatch.h.gch] Error 1
shell task failed, exit value: 2
Compiling patch failed ( /home/romor001/axoloti/axoloti-factory/patches/demos/synth/dreamy.axp )

#2

I commented out the rand() function in axoloti_math.h and now compilation of the patches works.
Still it would be nice to understand what the root cause of this is.

#3

hmm, I guess caused by a compiler update, which is now 'incompatible' with previous version. (not uncommon)

not sure if its a problem to use the stdlib rand(), my fear would be a slight performance issue, as the one in axoloti_math is inline, and stdlib is not.

however, resolution is possibly not easy...
- you could try to comment out the include of stdlib.h, but I fear it will be used for something else.
- try using -fpermissive, which might allow for redefinition.
- rename rand() in axoloti_math.h, but that would require changes to all objects that use it?!

#4

It seems like the .deb takes the approach of relying on the system arm-none-eabi which gets pulled in as a dependency rather than relying on the known to be working version that Axoloti's build process can pull in manually. You can see the patch compilation process going out to system directories, e.g. /usr/arm-none-eabi/include etc.

Compare the contents of axo_runtime_linux_1.0.12.tgz to what's included in the .deb. The former includes the whole arm-none-eabi toolchain while the latter does not.

Before the .deb is fixed you might try hacking your runtime directory to look like the .tgz to avoid the breakage coming from the system toolchain.

#5

Would it be a solution to define a dependency to a working version of arm-none-eabi in the .deb package?

#6

I might be wrong here but off the top of my head I think the idea with deb and dpkg is to only allow dependencies on specific release versions of the package. In other words, we get whatever the lastest version is in the repo and can't pin it to some other version.

Longer term solutions: include the working version right in the deb and make sure we don't declare a dependency on the system version.

The real way forward is to properly avoid the conflict on the rand function. I've never seen this problem before on any of the versions of the arm toolchain I've used. Need to do a bit on analysis to see exactly what's happening in the specific version you have. I can look it up in the Ubuntu repos, but can you try to grab the toolchain version you have from the command line?

Really we should do both.

#7

Not quite sure what you mean by this. I'll do it, but need -v.

#8

Not true, you can specify relationship eg < , >, = for depends.

Of course you are then dependent on the repo having specified version still available. This is usually ok, or you can did an alternative source.

Really it’s just we should have been explicit on the version esp with compilers which have a tendency to introduce breaking changes

Iirc, if you uninstalled axoloti and the compiler ,
and the. manually install (via apt) an older version of the compiler , then axoloti all will be ok

But I’d need to go back to my Ubuntu install to see what the working version is.

All that said the way forward is to fix in axoloti for new compilers - it may be this is already done in dev since I know johannes has updated the compiler a few times in dev.

#9

@jsilence Exactly. I'm just curious what the exact version you have is.

@thetechnobear Cool. Maybe we can override the version in the deb if the one we need stays available in the repo. I do like the idea of trying to isolate ourselves from those changes if possible though.

Edit: here's the full detail on what you can do with dependency declaration: https://www.debian.org/doc/debian-policy/ch-relationships.html
My only issue with pinning to a system toolchain version is that it might conflict with people who care about having the latest one available for other work; that's going to be a minority though.

#10

Ok, I now understand that I'm supposed to extract the version of the toolchain. What I meant with "-v" was that I need more verbose instructions. Sorry for the misunderstanding.

How do I get the version of the toolchain on the command line?

#11

On my way out at the moment. Check the man page or usage. Probably --version or similar.

#12

That’s depends on toolchain , many allow you to have multiple versions installed, and often have a kind of ‘select’ tool that’s changes the default version to be used.
Not sure about this one though!

Really I threw the deb package together as we didn’t have hardly any interest in it.
and as you will see on forum, the Linux community is split over many distributions - it’s worst case scenario - small number of users taking disproportionate amount of effort.
So we kind of assumed Linux users would be tech savvy to build themselves. But that’s not always been true.

anyway since then I’ve started distributing other stuff I do on different Linux platforms so got a better handle on the tools available, so could improve what’s there for next release

#13

One idea would be to do something like appImage or flatpak as a single Linux release rather than trying to target each distro's package manager.

Ha, I tend to agree that the Linux userbase who strictly needs a package and can't compile is probably small. But it would be cool to have a really frictionless Linux build if we can avoid wasting time on all the distro specifics.

#14

actually, a 'lightbulb' moment as a workaround....

according to build.sh , the gcc-arm-none-eabi we need, is
gcc-arm-none-eabi-4_9-2015q2-20150609-linux.tar.bz2

perhaps the easy way forward is to follow the 'build it yourself' method described in the linux install guide (?)
and then just point the runtime directly at the directory you build.

no need to mess about with apt at this point.

really this is quite simple, should just be a matter of

mkdir projects
cd projects
git clone https://github.com/axoloti/axoloti 
cd axoloti/platform_linux
./build.sh

assuming links are still all good, this will download everything needed

then in axoloti which you have previously installed, changed axoloti runtime in preferences to
~/projects/axoloti

of course, this assumes the build script its up to date... which may not be true :wink:

#15

Sorry for being dumb, but I am very very new to the Axoloti ecosystem. I have no idea on how to invoke "The Toolchain(tm)" on the command line. I'll happily provide version information of "a thing", if you tell me what "a thing" actually is.

#16

a stupid question @jsilence

did you install the axoloti_runtime from :

as explained in the install guide for linux? (did you follow this guide?)

this includes the toolchain for linux, so should just work?! (as far as I remember, been a long time since i installed it!)

#17

Sorry for the lack of specifics, @jsilence. Try running arm-none-eabi-gcc --version.

#18

By the way, I can confirm that the manual Linux build by itself definitely works. That's what I usually use. I've been able to run against more recent system arm toolchains on Arch as well. That's why I'm curious about the exact breakage with rand on your system. I want to grab the package for the exact version you have and try to see what's happening.

#19 
~/ > which arm-none-eabi-gcc
/usr/bin/arm-none-eabi-gcc
~/ > arm-none-eabi-gcc --version
arm-none-eabi-gcc (GNU Tools for Arm Embedded Processors 7-2018-q3-update) 7.3.1 20180622 (release) [ARM/embedded-7-branch revision 261907]
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
#20

Rereading the instructions for Linux I realize I only installed the .deb Package.

I followed the complete instructions now, but now it is not finding the board any more ("No available USB device found with matching PID/VID").

I'll tinker with it and figure it out. Applied the udev Rules while the board was disconnected. Maybe something hanging there.