Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

-s USE_XXX should accept -lXXX #8650

Open
Beuc opened this issue May 22, 2019 · 4 comments

Comments

Projects
None yet
2 participants
@Beuc
Copy link
Contributor

commented May 22, 2019

Hi,

I get a lot of errors like in my builds with 1.38.32 such as:

emcc -s USE_ZLIB=1 -o python Modules/python.o libpython2.7.a -ldl -lz -lm  
shared:ERROR: emcc: cannot find library "z" (`-s ERROR_ON_MISSING_LIBRARIES=0` to disable this error)

This is quite puzzling.
It would make sense for emcc to accept -lXXX when using a built-in port -s USE_XXX.

@sbc100

This comment has been minimized.

Copy link
Collaborator

commented May 23, 2019

The -s USE_FOO flags for libraries implicitly add the include paths and link flags that you need in order to use the library. You don't need to add additional flags. They would be definition be redundant. I don't love the USE_FOO system for including ports, but that is how it currently works.

I recently re-worked the ports so at least they have the correct names (libfoo.a).. but the name of the actual library produced by the port is still currently and implementation default and passing -lz implies that you know that filename is libz.a under the hood somewhere.

I kind of agree with your though, it would be nice some day to be able to consume ports simply by passing -lz. I imagine this being separate to the -s USE_FOO flags though. We could have embuilder be the way to build the libraries and have -lz be the way to consume them. Currently we have USE_ZLIB which means "build and consume".

@sbc100

This comment has been minimized.

Copy link
Collaborator

commented May 23, 2019

Are you saying that it used to work to pass -lz? Perhaps it was just failing silently prior to #8461?

@Beuc

This comment has been minimized.

Copy link
Contributor Author

commented May 23, 2019

From a porter PoV, I ./configure the target project with appropriate CFLAGS/LDFLAGS, which include -L and -s XXX options. The target project's build system will then expect my configuration to satisfy its link dependencies, which it unconditionally specifies as -lXXX.

That's what I think it makes sense for -s USE_XXX to provide a high-precedence equivalent to -L/hidden-emscripten-path -lXXX. Otherwise I have to patch the target build system, which would be emscripten-specific, time consuming and error-prone.

The issue is indeed all the more present with #8461 - as emcc used to warn in the past, and now fails. I can pass -s ERROR_ON_MISSING_LIBRARIES=0 everywhere but that sounds like a work-around and not a proper fix.

@sbc100

This comment has been minimized.

Copy link
Collaborator

commented May 23, 2019

Yes, its seems that this has always been an issue just hidden by the fact that ERROR_ON_MISSING_LIBRARIES used default to false. I suggest you add ERROR_ON_MISSING_LIBRARIES=0 to get the old behaviour until we can come up with a more elegant solution.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.