The sound triangulated was in cryogenic liquid oxygen at 50 PSI. The speed of sound in that is approximately 1 kilometer per second.This paper is about calculating the exact speed. Elon talked in the conference about reading telemetry with millisecond accuracy. But this would yield only 1 meter resolution.

That's not the way it works. When cross-compiling, configure runs on the host. It tests that things compile. It doesn't test that they run.

Roger,

This is great. It does look like a 1:1 mapping to what we expect autoconf to do, except neater and maintainable.

The only problem with selling this to GNU folks is that it would make CMake a prerequisite to everything. But I think it's worth it. And then there's inertia. And the language isn't as pretty as we'd like.

Can you see any other possible objections?

Thanks

Bruce

the Emacs vs VI war is over (Emacs won)

Nope. B-)

When I got my first UNIX box, back in the '80s, it had two megabytes and did NOT have demand paging, which would have allowe a larger virtual image to run. That was too small to compile emacs. (The joke at the time was that the name was really an acronym for Eight Megabytes And Constantly Swapping. B-) )

So I learned VI. Then I used it VERY heavily for years, on the original conferencing system whose software was later ported to The Well. After that a number of editing idioms were "wired into" my hindbrain and I could do the things I wanted to do with text very efficiently with vi.

As machines improved I tried emacs several times. Each time I found that the stuff I depended on took about 1.5 to 3 times as many keystrokes. This was too much of a penalty to pay for the handful of features it offered.

At one point I considered going to it but running in a vi emulator mode and gradually migrating to native idioms. But I discovered that, kitchen sink that it was, it had TWO vi emulator modes, each with distinct deviations from vi (alias "bug sets"). With one vi emulator, even with substantial shortcomings, I might still have made the shift. With two there was no easy way to chose, so I didn't bother.

Now I'm using vim, which is close enough. One of my regular colleagues is an emaxian rather than a vithian and we get along just fine. B-)

Also: It's not clear to me which group should be handling this. It seems to be a conflict between how two projects downstream of the compiler itself are handling a global namespace.

I'd only expect the compiler guys to fix it if they decided the downstream stuff was a problem and pulled part of it into their own stuff to settle the matter.

Wouldn't it be easier to check your bugzilla ticket?

There were already several tickets out on it (and flames from the maintainers about duplicates) so I didn't file another. None of them seemed to indicate that anyone, let alone the core compiler crew, were intending to do anything abut it.

I was hoping someone more actively engaged in either reporting or dealing with the issue might happen to be participating here and care to chime in. B-)

Meanwhile, others should know that there IS (or, we can hope, WAS) an issue before they make plans to try to use the toolset for a new project.

Cmake are scons require that they already be installed.

This is assuming that a shell capable of running ./configure is available on all of your platforms.

I should correct that: automake builds things by creating makefiles. The configure script created by autoconf is concerned with configuration rather than building, but its output is input to automake.

CMake, Scons, etc. are mainly targeted at dependency-based building of programs. Autotools doesn't really build anything. It goes through a long list of system facilities, determining if each is present. For many, perhaps most of them, it builds a little C program that exercises the facility, and sees if it compiles.

Now, there's another poster who says you really can do this with CMake, which I'll have to look at.

Did they fix the conflict between gcc-multilib and gcc-arm-linux-gnueabihf?

Since Ubuntu Trusty was released, over a year ago, there has been a conflict between gcc-multilib (needed for building and running 32-bit application on 64-bit Intel/AMD architectures) and several cross compiler suites including gcc-arm-linux-gnueabihf (the cross-compiler suite needed for developing applications for ARM processors, such as those on the BeagleBones and many Internet of Things devices.)

This means if you want to do cross-development and you have a 64-bit machine running a 64-bit install and doing builds for itself for both 64 and 32 bit environments, or running some 32-bit applications, you can't just install the cross-tools from the repository and dig in. You need a separate machines for cross-development, or you need to take time out to do your own hacking of the tools.

I've looked around the net for solutions: The issue seems to be a disconnect between teams, primarily over conflicting uses of the symlink at /usr/include/asm. But I haven't found any clear description of how to work around this, nor has the problem been fixed in the repositories. After over a year I find this very disappointing.

Has this been addressed with this new release of the underlying compilers?

This isn't really a problem for StackOverflow. It's a problem for the developers of GCC and its libraries, and a policy problem for the overall GNU project in that Autotools is IMO too much of a mess to live, and is a barrier to participation as it stands. That's why I talk about it here instead of just submitting it as a bug report.

I would like to see someone come up with an alternative. That alternative is not CMake or Scons, etc., because those are build systems rather than systems that probe a platform for fine differences in the programming environment and produce a set of macro switches as output.

Yes, I can get a pre-built toolchain or a building kit, but it doesn't really solve the problem of not being able to build the current GCC with the right settings in its configure script and to use it with the right C library and kernel headers for my device. Should I modify any of those toolchain kits to do that, they'll come up with the same errors.

Besides devKitARM, there is the collection of toolchains mentioned here. I am getting most of my clues from the Emcraft toolchain, which is the only one for the SmartFusion. And we're great friends with Emcraft, but I want something a bit newer and a different build-tree style.

My last approach to the libstdc++ mailing list, here, was left unanswered. I figured out the problem behind that one, but it would have been nice to get some advice.

Autoconf doesn't have a --synclines flag, but I might be able to pass it in the M4 environment variable. I'll give it a try.

I've been configuring a toolchain for Algoram's programmable radio transceiver, which has a SmartFusion 2 containing a Cortex M3. Until today, I've been working with GCC 5.1. Building GCC for cross-compilation on a no-MMU, no-FP processor and a software platform that doesn't support shared libraries isn't trivial, though it should be. GCC has many configure scripts, one for each library that it builds and at least one for the compiler. You run across many configure issues which are difficult to debug. For example, the configure file, a macro-expanded shell script, doesn't have source code line numbers from its configure.ac file. Error messages do not in general indicate the actual problem, and are difficult to trace. Figuring out what to fix is far from trivial. I ended up not being able to use multilibs (which would have allowed me to build for FP processors like Cortex M4F as well), couldn't link in ISL, couldn't build libjava.

Some of these are beginner problems - I'm new to building cross-toolchains and have avoided autotools as much as possible before this project. But not all of them.

One would think that we could build a better system today than such voluminous M4 and shell. Perhaps basing it on a test framework might be the right approach.