I tried this last week and kept failing miserably. It seems to be stuck on wanting aclocal 1.15.0 however the only versions which seem to be available are 1.16.1 and 1.13.? (Don’t remember sorry).
What is the correct way to deal with this. Using an OS image a couple of weeks old with the current updates in VirtualBox. x86_64 Haiku, and x86_64 lubuntu 18.04.
That’s a known bug not specific to ARM, jump on IRC sometime and you’ll probably be able to get some help on that.
Also I think this may have been fixed?
IRC is a little difficult for me. I’m usually in front of the PC for short slices of time. Not great for holding up a conversation.
Would you happen where the bug lies, so I know what needs updating?
Thanks for the quick reply by the way.
Also you can just Jump on IRC and ask… then check the logs later https://echelog.com/?haiku
waddlesplash had me try a few things a few days ago I think friday evening look at the logs from then. I would try building a few checkout first again though.
If you know the generated files are up to date, you can override with make ACLOCAL=:
From the documentation:
By default, it only remakes those files that are older than their sources. The environment variables AUTOM4TE, AUTOCONF, AUTOHEADER, AUTOMAKE, ACLOCAL, AUTOPOINT, LIBTOOLIZE, M4, and MAKE may be used to override the invocation of the respective tools.
While I haven’t tested the result yet, it did build successfully. I wasn’t paying full attention tbqh because it’s been a long day but it appears to have worked out. There’s another program which I give environment vars this way.
ACLOCAL=: ../configure -j2 --build-cross-tools arm ../../buildtoolsGreat that it built successfully!
It seems to have. The built gcc spat back the correct triplet.
I was so unclear before. There’s another program which I build regularly which needs a few variables set or it won’t build or run right. Prepending them is the method used. I wasn’t thinking and did the same on the configure command and arguments suggested by the documentation.
I’m glad it worked too. It’s not often a mistake works out better!
Should we include that in the configure script? Wouldn’t it solve this problem for everyone?
It would, and it’s actually better than the hacky solution I sent to @cb88 that touched all the files aclocal would have regenerated. I’ll look at applying that later today.
Somebody else has tested it first?