Remove some magic handling of native shared libraries#20886
Conversation
fd51a94 to
f8e1771
Compare
| - Emscripten is now more strict about handling unsupported shared library | ||
| inputs. For example if you passed `/usr/lib/libz.so` emscripten used to | ||
| magically redirect that to its own internal libz if it could find one. | ||
| (#20886) |
There was a problem hiding this comment.
Maybe this could say what a user should do if they run into this? I guess they should provide a absolute path to an emscripten dylib, or emscripten will search its own library paths if the path isn't absolute?
There was a problem hiding this comment.
You shouldn't be passing system libraries to emscripten at all. So I guess the advice would "don't use host libraries with emscripten, you need to use emscripten-specific libraries".
|
Updated ChangeLog entry to be even more explicit about that changed here. PTAL |
We had this rather strange (I imagine completely unused) feature where is emscripten is passed a concrete path to a shared library file (e.g. /path/to/libfoo.so) and it could determine that the shared library was not indented for emscripten then it would instead search the library for other things called `libfoo` that might work. This seems too magical at best and harmful/confusing a worst. The presence of this feature is blocking the way for some internal optimizations and refactorings (e.g. emscripten-core#20884)
001af32 to
c8a43e7
Compare
| diagnostics.warning('map-unrecognized-libraries', f'unrecognized file type: `{arg}`. Mapping to `{flag}` and hoping for the best') | ||
| state.add_link_flag(i, flag) | ||
| else: | ||
| input_files.append((i, arg)) |
There was a problem hiding this comment.
Perhaps we could add an error here that suggests the proper form, to help people update? That is, if /abs/path/libfoo.so does not exist, but libfoo.a exists in the sysroot, we could say Absolute path .. provided, but the contents there are not valid for wasm. Did you mean -lfoo ?
There was a problem hiding this comment.
I'd rather not for the following reasons:
- I think its unlikely anyone is actually relying on this/
- I think the
unknown file formatis pretty reasonable and actionable - Do a search of all the library paths at this point is tricky.. especially given the we sometime build libraries on demand and they might not exist yet.
- Its hard to recommend
-lfoojust because somebody passedsomepath/libfoo.so. In most cases the solution to "unknown file format somepath/libfoo.so" is to rebuildsomepath/libfoo.sowithemccnot to replace that with-lfoo
We had this rather strange (I imagine completely unused) feature where is emscripten is passed a concrete path to a shared library file (e.g. /path/to/libfoo.so) and it could determine that the shared library was not indented for emscripten then it would instead search the library for other things called
libfoothat might work.This seems too magical at best and harmful/confusing a worst.
The presence of this feature is blocking the way for some internal optimizations and refactorings (e.g. #20884)
I tracked the addition of this feature back to 03033b2 in 2012.