Not quite sure what you mean by this. I'll do it, but need -v.
Fresh installation on Ubuntu 18.04.3 - Compilation of patches fails - 'int rand()' was declared 'extern' and later 'static'
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.
@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.
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?
On my way out at the moment. Check the man page or usage. Probably --version
or similar.
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
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.
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
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.
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!)
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.
~/ > 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.
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.
Oh my golly, looks like I picked a "charging only" USB cable. Switched cable, purged .deb package, installed runtime, applied udev rules, installed .deb package.
Works now without the above mentioned error about the rand() function.
Next time no more "jaja, ich weiss how to install a debian package" half-assed-non-reading of the fine instructions.
Apologies for wasting your time!
Ah ha. Was the intent always to have users install both the deb
and the runtime?
Maybe you had an arm toolchain installed before you installed the deb
. Are we sure that the deb
pulls in the toolchain? Need to check that.
Yes, I likely have installed an Arm toolchain installed since I was dabbling with Armbian (sans Docker) some time ago.
Sorry again, and thank you for your patience!
(Ordered an Axocontrol board today. Looking forward to the delivery)
At least the half functional cable is not going to trip me up again.
BTW doing the same with CAT 5 Ethernet cables after I discovered bosses mother is rescuing them from the trash.
@jsilence your not the first ( and won’t be the last) to be fooled by a usb power only cable
Glad it’s working.
( Sorry, it’s partly my fault I’ve not been doing a lot on the forum recently so haS forgotten some of the common pitfalls.)