Emscripten 6.0.6 passes autoconf check for `getwd` as `yes`, but it's not available in reality

[vadimkantorov]

At least at https://github.com/TeX-Live/texlive-source/tree/tags/texlive-2023.0, autoconf-generated standard configure produces ac_cv_func_getwd=yes:

I suggest it should be somehow fixed to fail this autoconf check (AC_CHECK_FUNCS([getwd]) passes under Emscripten?

If can't be fixed, could introduce some flag to emconfigure for it to append the hack ac_cv_func_getwd=no (or provide an autoconf cache file with all these known overrides), or document it somewhere (as part of autoconf checks which are known to be buggy under Emscripten)

[sbc100]

According the an AI investiation the root cause here that busytex/busytex is passing -sERROR_ON_UNDEFINED_SYMBOLS=0:

https://github.com/busytex/busytex/blob/df56205af19180fe1d29be5a3150e2c5077337cb/Makefile#L137-L138

The way autoconf detects the presence of symbols depends on undefined symbols being errors.

[sbc100]

I added a specific test to verify that we are returning the right thing here: #27591

[vadimkantorov]

The way autoconf detects the presence of symbols depends on undefined symbols being errors.

This does not affect any other function detection. But I'll double-check.

How do we have -sERROR_ON_UNDEFINED_SYMBOLS=0 for building final binaries, while not having this applied to autoconf checks?

[vadimkantorov]

Maybe worth also adding into docs that -sERROR_ON_UNDEFINED_SYMBOLS=0 (typically needed for system function or other process-related things, not used on the wanted code path) messes up autoconf?

[sbc100]

Sure, I would advise against using -sERROR_ON_UNDEFINED_SYMBOLS=0 in general since its produces programs that will likely not run. Perhaps we should simply deprecate it. Do you know why tex is using it?

[vadimkantorov]

I use it as a hack to force compiler ignore syscalls/libc functions missing from Emscripten - e.g. system() and process/popen/spawn-related functions (and also getpass) - these are used in TeX programs to invoke third-party programs. Sometimes these functions are used on the code path which will not be executed, so ignoring them at linking time is fine

So an alternative could be supporting more of standard functions, but just make them fail (return error or even abort), or enable this as some sort of opt-in polyfill.

But also somehow it's strange to have these LDFLAGS being applied to autoconf checks... I wonder if it can be hacked around somehow

[sbc100]

Emscripten does include a stub for system(): https://github.com/emscripten-core/emscripten/blob/main/system/lib/libc/system.c.

Also for popen:

emscripten/system/lib/libc/emscripten_libc_stubs.c

Lines 199 to 202 in a04d0be

	weak FILE *popen(const char *command, const char *type) {
	errno = ENOSYS;
	return NULL;
	}

If there are linux-specific function like getpass that we don't have any kind of stub for then I would suggest of the following 2 approaches rather than resorting to using -sERROR_ON_UNDEFINED_SYMBOLS=0:

1. Try to configure the software in question use macros like HAVE_GETPASS (and aufoconf checks). Especially for linux-speific calls I imagine most software already does something like this.
2. Create your own stubs for the symbols you need and link them in using LDFLAGS=mystubs.o.

[vadimkantorov]

For instance, if I remove -sERROR_ON_UNDEFINED_SYMBOLS=0 from CFLAGS, I get an error later on:

wasm-ld: error: dvipdfmx.o: undefined symbol: getpass
wasm-ld: error: dvipdfmx.o: undefined symbol: getpass
wasm-ld: error: dvipdfmx.o: undefined symbol: getpass
wasm-ld: error: dvipdfmx.o: undefined symbol: getpass

[sbc100]

Right, for cases like getpass where we don't have stubs in emscripten I think (1) and (2) from #27583 (comment) as the way to go. -sERROR_ON_UNDEFINED_SYMBOLS=0 is probably not best solution for various reason. For example, it hides real link failures, and it causes false positives in configure checks. I will update the docs for ERROR_ON_UNDEFINED_SYMBOLS to make it more obvious that its not recommended.

[vadimkantorov]

I would propose to maybe make ERROR_ON_UNDEFINED_SYMBOLS more granular, e.g. to allow -sERROR_ON_UNDEFINED_SYMBOLS=popen,getpass to eat only these errors

Of course, it would be best to have software properly checking and fall-backing for absence of these functions, but sometimes it depends on patching ancient upstream things like TexLive. Maybe hack like -sERROR_ON_UNDEFINED_SYMBOLS=getpass could be a good temporary solution.

It used to choke on some popen variant some years ago, I'll report again when I try it again