Hey,
I’m having a few problems. First of all, I wonder why it says in the wiki: “it is normal for there to be a few warnings when compiling libDaisy”, but at the same time in the makefile for libdaisy (and DaisySP) the -Werror flag is set, so any warning will stop the build process.
After editing the makefiles to substitute -Wno-error, I got a bit further. But now I’m stuck at a build error in drip.cpp:
modules/drip.cpp:20:18: error: 'rand' was not declared in this scope
After investigating header files, it seems that rand() is defined in stdlib.h (on my system), but in drip.cpp only math.h is included.
Should I just add #include <stdlib.h>, or is there a better way?
I should add I am using gcc and arm toolchains from the Debian 9 repositories, not the more recent versions that you suggest. That is because I really dislike having software scattered about, not managed by the package manager.
I got a bit further, just by including stdlib.h.
But, now I’m getting complaints about a number constant in math.h, M_PI.
Somehow it is not defined, so I am getting an error about it in atone.cpp (even though it includes math.h).
The #define's in my math.h are wrapped in some conditions #if defined __USE_MISC || defined __USE_XOPEN, I’m asuming those are not true for some reason. 
This is getting to be kind of kludgy build, I guess I will just have to define them in the module headers then…
Finally! I managed to kludge my way to a blinking LED 
I had problems with M_PI in most of the module source files, and M_TWOPI (which was not referenced anywhere in my math.h, so I actually had to go to wolfram alpha to calulate it to 20 decimals 
).
In a few source files, like mode.cpp, you even do this:
#ifndef M_PI
#define M_PI 3.14159265358979323846f /* pi */
#endif
If only that had been done in all of them, there would have been no problems. As to the other issues I had, maybe -Werror in the makefiles is a bad idea if you expect warnings 
The missing rand(), dunno, maybe it is defined in math.h on most other systems?
Anyways, it works now. I hope it may be a useful read to someone, probably on linux, like me 
Thanks for sharing your journey! Sorry it ended up being such a trek. At least this may help some others in the future.
I’m not sure which version of the compiler are in the package manager in Debian, but I have seen some issues with older versions of the compiler (not necessarily related to the standard libraries, though). Something potentially related is the lack of a std version in the makefile’s flags. I saw this cause an issue on Debian, and we need to add a c++ version to resolve many errors.
That said, I’ve found that a number of the resources for the daisy must be newer versions than are provided (openocd for jtag debugging, for example, didn’t have support for the stm32h7 processor until fairly recently).
1 Like
As for the PI stuff, a migration to built-in defines (in dsp.h) Is in the works. But, as you mentioned, is very partial and inconsistent at the moment.
1 Like
Sounds good!
And yes, I had to add -std=c++11 to CPPFLAGS to get through constexpr errors. And -Wno-error.
But, I’m not even on the most recent Debian, so was kind of asking for trouble (and expecting it).
gcc -v shows: gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)
@kborch I have WSL set up for testing some debian stuff on my office PC, and it looks like its on a similar version, and the arm-none-eabi tool chain’s latest version is 5.4.1 (I have the same normal gcc version as you it seems).
It’s worth mentioning I can see all the errors/warnings you mentioned above when attempting to compile this way.
The warnings and such seem to persist when rebuilding on other OSes (i.e. Windows) if the std flag is set.
I’ll look into standardizing a version for each library (probably 2014), and then doing clean up based on the issues that come with it. Glad you were able to get it working for now!
1 Like