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 example Roger Leigh posted above, for libtiff, is compelling. If you read it, you'll see it is a 1:1 mapping to what autoconf does, and it's a lot neater and more maintainable.

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.

Exactly.

Bolt for nuclear submarine piping: $2

Paperwork to prove it meets all the mil spec and you can trace the manufacturing back to the raw material source: $1000

Being able to surface at end of cruise: Priceless

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.

Given how sliw the procurement process works and at the end you get the lowers"qualified" bidder who may or may not provide what tou need it isno wonder people bypass it any way they can. Of course, DOD can't just have one giant blanket purchase agreement because that wouldn't spread the wealth around to enough businesses in as many congressional districts as possible.

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.

In that case, AM might be liable for damages if someone paid to have the information deleted and it turns out it wasn't and then later gets stolen and released causing damage to the account holder. IANAL, but it would seem they would have at least an expectation the data was deleted, paid a consideration for AM to take a certain action (deleting information) in exchange, failed to do so as promised and as a result some suffered damages. While there is probably some T&C fine print that attempts to absolve them of all responsibility I would argue they were negligent in not deleting the data and safeguarding their systems and thus still liable. Given they are looking at IPO money they would have deep pockets for a class action suit.

I wonder if someone got laid off or feels screwed out of IPO shares? It would seem someone who had access to accounts might be able to grab the info, or at least enough to convince AM they have.