search

df8oe / UHSDR

SDR firmware and bootloader with configuration files for use with Eclipse, EmBitz and Makefile
Other
360 stars 189 forks source link

Latest commit b79484d build fails #1784

Closed roelandjansen closed 5 years ago

roelandjansen commented 5 years ago

Latest commit b79484d seems to fail the build here:

after pulling the latest code:

[CC] drivers/ui/encoder/ui_rotary.o [CC] drivers/ui/radio_management.o drivers/ui/radio_management.c:117:5: error: initializer element is not constant bi_80m_r2, ^ drivers/ui/radio_management.c:117:5: note: (near initialization for 'bandInfo_combined[0]') drivers/ui/radio_management.c:118:5: error: initializer element is not constant bi_60m_gen, ^ [....] const BandInfo *bandInfo = bandInfos[0].bands; ^ make: *** [Makefile:264: drivers/ui/radio_management.o] Error 1 roeland@taplop:~/src/UHSDR/mchf-eclipse>

db4ple commented 5 years ago

Please report which compiler version and package you are using on which operating system! Thank you!

We are running Travis Build tests for the commits (for this commit: https://travis-ci.org/db4ple/UHSDR/builds/558511560?utm_source=github_status&utm_medium=notification) and these pass without problems.

Most likely your compiler is "too old". Did you do other modifications to the Makefile (or code) or are you building the commit unmodified?

roelandjansen commented 5 years ago

arm-none-eabi-binutils-cs-2.25-3.fc24.x86_64 arm-none-eabi-newlib-2.2.0_1-7.fc24.noarch arm-none-eabi-gcc-cs-c++-5.2.0-4.fc24.x86_64 arm-none-eabi-gcc-cs-5.2.0-4.fc24.x86_64

db4ple commented 5 years ago

OK, I verified, the issue also exists if we build with Travis and gcc 6 and 7. Turns out, only gcc 8 happily compiles this code. As a quick fix, I recommend to switch to use the ARM gcc packages, which you can simply untar somewhere and use as per instructions in our Wiki (OPT_GCC_ARM=... make ...).

We'll look into this.

roelandjansen commented 5 years ago

I'll see if the other projects can handle an update as well; the repo I git the compiler from has not been updated in a while (read: empty). (md380 tooling and adalm pluto)

df8oe commented 5 years ago

Please take the toolchain from this link: https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm/downloads

roelandjansen commented 5 years ago

Andreas,

that would be a very very very very very very very very last resort. In general if it's not packaged, it won't be installed. ;-)

Anyways, I may have cross-arm-none-gcc8-8.3.1+r271793-1.2.x86_64.rpm and friends. I'll check the versioning against your link and see how much it differs (it is v8 for sure).

df8oe commented 5 years ago

Sorry Roeland - but this should always be the first resort! Or you do have a Distro with very recent software like Arch based distros. It took only 3 days from release of the new gcc to arrival at the "official repos" :) If you want to have newest software using other distros you normally have to leave the way of "packages"...

db4ple commented 5 years ago

Hi, the recommended "package" is not interfering with your normal installed software. You just unpack it in a directory of your choice, that's it. And you tell OUR makefile via OPT_GCC_ARM variable where this directory is (well, the bin directory inside this directory structure). No other project would even notice you use the compiler. That is the beauty of it. Anyways, I understand your resistance to install just another compiler, but at some point we may drop compatibility with gcc 5, as this is a fairly "old" compiler and newer versions are easily accessible for use on any distribution, see above.

However, my fix in #1785 will bring back compatibility in this particular case and it was surely a good thing you reported the problem as it was a problem which had to be fixed.

roelandjansen commented 5 years ago

thanks. I'll let you know.

ps it's not that a different compiler is the biggest issue -- it's the fact that it's not packaged (yet).

roelandjansen commented 5 years ago

the build went OK.

db4ple commented 5 years ago

Well, this "package" is intentionally not packaged as a distribution-specific package by ARM so that it can be used exactly in this manner on different distributions and you can also have many different packages in parallel without problems. Since a cross-compiler is fairly self-contained and does not have real external dependencies, it is fairly easy to do.

Anyway, you don't have to like it or use it.