Same goes for htobe16, etc., which appeared in glibc 2.9.

So, just to be sure what's going on.

What is the host? A Android device? In such case, it should not use *_linux but *_android as well.

Or are you using the toolchain to build for the host on a linux box? That should not be the case.

Cheers,

• Anders

  ---

  Set owner to @zanderso.
  Added NeedsInfo label.

When building Android (which we have to do to get an Android WebView based on Dartium), things built for the host Linux machine rather than the Android device, like gen_snapshot, etc.) are built with a custom toolchain in the Android tree based on glibc 2.7. I'm not sure what the reasoning behind that is, or how difficult it would be to change, only that this causes the Dartium Android WebView build to fail.

This sounds very odd to me. It works against the purpose of splitting out to *_linux and *_android. Things build for host should be build using the default host toolchain. Is this something I can help look into?

I agree it is odd, and I agree that things built for host should use the host toolchain, but unfortunately to be part of an Android build, things we build for host for Dart will need to be built by a Linux toolchain based on an old glibc. So, I think it's not so much a *_linux vs. *_android distinction in Dart, as it is that some of our *_linux implementations are not compatible with older glibc.

The changes needed should be fairly minor. Maybe I'll just draw up a CL and send it out.

By "The changes needed should be fairly minor." do you mean that you are just going to stub out the APIs which are not present, and then we cross our fingers that they are not needed for the snapshot generation running on the host?

That is a really good point. The eventhandler should not be needed at all for snapshots, so maybe we should move that into io_builtins?

And I agree with you Zach, it is indeed an old-glibc issue.

That's what I'll do for the timerfd calls in eventhandler_linux.cc. For file_system_watcher_linux.cc maybe we should just get rid of inotify_init1 like we already did in the Android implementation?

For htobe16 etc. my plan is to include the macro definitions we need if the glibc version is < 2.9.

These changes are sufficient for Dartium WebView to build and run successfully in the Android tree.

Zach, we no longer compile the io part for host. Is this sufficient for you?

• Anders

In runtime/platform/utils_linux.h we use some macros (htobe16, etc.) that don't appear until glibc 2.9. I need to check whether they are still a problem.

Yes, it appears that the functions in platform/utils_linux.h are used by lib/typed_data.cc, which we probably can't avoid. However, I'm not sure we're really going to be trying to maintain this build configuration. I'm going to mark this issue as Waiting until we figure that out. I'll also remove Area-IO since that part is sorted out, now.

cc @iposva-google.
Removed Type-Defect, Area-IO labels.
Added Type-Enhancement, Area-VM, Waiting labels.

@zanderso is this something we are looking at? maybe we should close this issue.

I think this is stale.